I always assumed that when I uninstall a Codename One app (Android and iOS) all its data in the Storage and in the home path of the File System Storage is also cleaned... it seems so in my phones, but this is not the case on the Android phone of one of my friends (I'm referring to the same app developed by me).
Is there an explanation? Is it possible to be sure that all app data is cleaned during the app uninstalling? This is particularly useful during the software development.
Could this behavior be the one described in the answers to the question An Android app remembers its data after uninstall and reinstall?
Thank you
I'm guessing here but it could be related to Android backup support which restores the data. Otherwise if you used FileSystemService and stored data in he SD card area that won't be removed on uninstall.
For the former we have a build hint: android.allowBackup=false
I have some existing Windows Phone Silverlight applications. I am considering porting some of them to universal apps. I can find a lot of information about the development side of things with regards to the port, but nothing that talks about the deployment issues.
For example, my existing WPSL app is a paid app with free trial and some customers have purchased. Do I need to do anything to ensure those paid customers continued to receive the non-trial features if I push a universal app package? The purchase API's are different, are the backend servers/purchase records compatible, or is there no way to keep paid customers at the paid version?
Also, what about app settings from isolationstorage settings and data files saved to local storage by the app? Will these be kept and accessible through the new API's when the new package is downloaded as an update, or will the fact the package is a different framework/version/appid cause the data to be deleted? Do I need to give the package the same id's as the Silverlight version to ensure all this stuff just works?
Thanks in advance.
It should just work without needing to do anything fancy.
It will be the same app, just a different implementation. Your paid users will stay paid and your upgrading users will keep their data.
If you associate and add the new appx to the same app entry on the dashboard then everything should work smoothly. When you associate the runtime app the product ID, etc. will be set to match the existing version in the store (via a mapping since the actual values are different)
IsolatedStorage maps to ApplicationData.LocalFolder and LocalSettings (this was already true on Windows Phone 8 - you could use either API)
See What's next for Windows Phone 8 developers for an overview of your options.
See Migrating your Windows Phone 8 app to a Windows Runtime XAML app for information on feature changes you'll need to be aware of.
I have developed a windows 8 app and I wish to install the app on 10 devices and also when I alter the app I wish to automatically upgrade the app installed on these 10 devices. I do not wish to use the windows store and the app and devices have the necessary certificates needed. Is there a way I can sideload the app to the 10 devices and upgrade the app easily without using a hardrive to uninstall and install the app on each device?
Altough this was asked a while ago i want to answer this, as i myself struggled a long time sideloading LOB-apps and Microsoft almost makes no efforts of clarifying the mess of their licensing programm.
You need to get a sideloading key, you can get it from the microsoft volume licensing center (it is not easy to find, best you ask a distributor partner) costs 100$ and is as far as i know for 25 devices. You need to be partner to obtain such a key.
UPDATE: for unlimited devices (see article posted from user3123726)
FYI: i doubt it but if you plan to have all devices in the same domain you do not need a sideload-key
On the device where the application should run
install the app certificate into 'trusted root certificates' and 'trusted publishers'
install and register the sideloading key
for installing:
/C slmgr /ipk 00000-00000-00000-00000-00000 //your side loading key
for registering:
/C slmgr /ato ec67814b-30e6-4a50-bf7b-d55daf729d1e //for everybody the same key
For publishing and updating the app Microsoft has a service called 'Intune' where you can register your devices and deploy store apps to. I have tried this solution and really couldn't make it work. It worked sometimes but had a lot of crashes and freezes with no usable error message. I highly recommend to write your own update function as i lost many many hours trying to get it to work. It also seems like nobody really is using this solution as it has only 12 reviews in the app store and no forums whatsoever talking about it. However if you wish to try see this link:
https://technet.microsoft.com/en-us/library/dn646972.aspx
You'll need to install the 'Company store app' on each device.
If you tend to write your own update/install mechanism you can use this Powershell command to install the app on the device. You could use dropbox to distribute the packages to the devices and write a service which runs the powershell.
Add-AppxPackage -Path "yourapp.appx" -DependencyPath "Dependencies\x86\appdependency.appx"
I just heard that a company I do work for may be bringing in the Pyxis Mobile application development system. When I google it most of what I find is from the company's web site and that is not very informative from a geek perspective. Can any one shed some light on what sort of programming environment it is and what programing language is involved (please let there be a text based language). Any additional information would be great.
Note: the company/product changed their name to Verivo in January.
Full Disclosure - I work as an engineer at Pyxis Mobile. However, I have been in the mobile space for 7+ years and have evaluated several approaches to mobile so hopefully this is helpful.
Pyxis Mobile provides a set of tools and components to build cross platform mobile applications. Let me outline them first.
1. Application Studio - All application development, backend integration, user provisioning and application maintenance/debugging is done w/in this tool. Application Studio (for now) is a Windows based desktop app.
2. Application Clients - Pyxis Mobile provides native client runtimes for iPhone, iPad, BlackBerry, and Android devices. These runtimes get branded for the customer through a build service and are primed to point to a specific Application Server URL.
3. Application Server - Pyxis Mobile App Server runs on the .NET stack (on IIS). All client communication is proxied via this server. This server is able to connect to varied of backend systems (via the Plugin Framework listed below) and respond to the client in a mobile optimized manner. This server needs a SQL Server (2005 or newer) for configuration access, session management, logging and more.
4. Plugin Framework - The Plugin Framework is a backend component that provides system specific pre-built access to several of the enterprise and cloud based systems (Oracle, Siebel, SAP, Salesforce.com, social feeds, REST/SOAP web services, etc.) and also offers an API layer in .NET and Python (using IronPython) to allow even further customization. A plugin is essentially comprised of one or more DLLs or a Python file. These assets are then dynamically loaded to normalize communication between Pyxis Mobile and the customers' backend systems.
5. Push Services - This provides a cross-platform push layer that can poll a backend system for change and alert a mobile device via BlackBerry Push, Apple Push Notification Services (APNS) or Android's Cloud to Deice Messaging (C2DM).
6. OverWatch Analytics - This is an optional (but included) component to track users/devices and provide integrated analytics on what the users are using and what kind of devices and locales makes up your users.
The application itself is "coded" via configuration that is build in App Studio. Pyxis Mobile abstracts away from the code so that you can work at a higher level without having to worry about the wide array of device variances (GPS, touch screens, camera, accelerometer, push, screen resolution, etc.). You can drag fields onto a from, connect screens via menus or buttons, set up caching rules and more in this graphical utility. This configuration (essentially think of an XML like document) is interpreted by the native client layer to produce a rich application. There is also a scripting layer in Lua that allows to really customize behavior via code.
The real value of Pyxis Mobile comes up when you have change to make. The clients check for new configuration at app startup or if the server forces the client to get new configuration. This gives you great agility. Lets say once your application is deployed you want start using the swipe gesture to go next/prev through a set of records. This change on other platforms would mean writing some platform specific code to trap and interpret the swipe to perform a navigation (you couldn't trap a swipe on a non-touch screen). However, in Pyxis Mobile this is a simple configuration change that can be quickly deployed to the App Server and the clients automatically download and use the new configuration. No compilation, no redeployment or re-download for the end users.
I could keep going, but hope this provides some level of guidance.
Beware of Pyxis Mobile. While many of the things they say do work, there are some serious platform issues (as a geek) which I've experienced.
1) No version control system process. The Application studio can basically only be developed on by one person at a time or you risk having your changes overwritten by a fellow developer. The "principle of last save" is very much in play.
2) No unit test coverage. This isn't the biggest issue for a lot of people, but it's a concern for anyone who wants to work in the Enterprise world.
3) The middleware server gets you some value, but it's also a PITA to work with. There is no concept of "client side storage" unless you consider the middleware server the client side. If your phone goes out of coverage, your app won't work. Again, this might not be an issue for you.
4) The application has no true scripting language to work with. The middleware server allows you to intercept requests and responses and modify what you're doing there, but it's not the most elegant solution considering that a native application can have something as simple as "if this then X else Y." This can be accomplished with Pyxis, but the whole process is convoluted and more complicated than one would think it needs to be.
5) Lack of documentation. There's some training guides and the GUI is easy enough to get around for simple apps; however, when you need to do something with guts, you're left relying on Pyxis professional services. There's really no developer community to pose questions to.
I have more complaints, but they are more opinion oriented than Q/A oriented.
I just got note about the most recent comments. I don't want to turn this into a thread of back and forth, but did want to throw a couple of quick notes.
Regarding the points on version control and documentation/developer community - no big contest there. We are definitely working on these shortcommings. We have some basic pieces in place, but we have big plans to focus on this.
Regarding unit testing - we provide a very open interface to our middleware and backend components and they can be very easily unit tested with a bit of instrumentation. We run a ton of unit and integration tests internally. However, mobile unit testing is extremely difficult to get right. We'll investigate this further.
Regarding #4 around middleware and offline capabilities - things are a lot different now. With version 7.1, 7.2 and 7.3 our products have increasing become more capabale offline and now features a secure local database if necessary. I can provide more details as necessary, but you can certainly login and operate the app even if you are out of coverage for weeks at a time!
Regarding #5, we've had a scripting engine for over 2 years. Its Lua based and its actually quite powerful and fast. It was BlackBerry only till the most recent release. Given Apple's change of stance on allowing scripting we now allow scripting on BlackBerry, iPad, iPhone and Android as well now!
#RockMeetHardplace - feel free to reach out to me directly and I'll be happy to give you more detailed live demos of our latest platform. I am at - arunSPAMNOTatpyxismobiledotcom (drop the "SPAMNOT" and replace the at and dot). I happen to be the Director of Software and interested in knowing more about the issues you had.
Is there a simple and automatic way of checking if a visitor to my website (written in asp.net) is using the latest version of his browser? This would allow me to display a message to inform them that they're running an old version and that they might want to upgrade.
My website is tested on most broswers but I don't test old versions (such as Internet Explorer 6 etc). When one of my visitors is using such an old version, basically, I would like to encourage (not force) them to upgrade.
Of course I could do this myself by getting the version of the browser and look it up in my database but I don't want to have to maintain a 'browser version' database myself.
Any ideas?
Speaking as a user of websites, if I come across a site that advised me to upgrade my browser then that would be an immediate black mark against that site.
I might not be able to upgrade (if I'm accessing from a corporate network for example); I might have a specific reason for using a particular version (if I'm a web developer wanting to ensure compatibility with my user community for example).
So personally, I would say that a blanket disclaimer that you don't test this site on earlier versions would be the way to go. That's quite apart from the technical challenge of what you want to do.
Edit: as Yeti points out, however valid my concerns, I don't answer the question directly. This is done in Pace's answer, and the w3schools resource he points to gives you what you need to do this on the client side.