I have an app which requires its database to be replaced entirely whenever changes are made to the source data. I would like to have this update functionality built into the app, so that the app itself does not need to be updated (ie. re: Play Store), only the database file within it. I am considering hosting/updating the database file (I'm using SQLite) on GitHub for direct download via my application.
The information in the database is not sensitive so I am not worried about security. Additionally, these updates would happen relatively infrequently on a client's device -- 1 to 2 times a year at most.
Bearing in mind I'd like to keep this as free and simple as possible - is this an advisable approach?
Related
I am completely new to the Bitcoin scene. and have been researching a lot about it. I have also read the original white paper on it. I was looking into making an Andorid wallet where I could send and receive bitcoin. I successfully made that application I do have some questions though, I couldn't find these answers online.
I used BitcoinJ to make the Android bitcoin wallet. So here goes my questions
1) Using the latest version of BitcoinJ is this library safe to use in a production enviroment?
2) What other security features can I implement to make wallets secure as possible if im going to store addresses in a NoSQL db.
3) From the limitations section it says this:
The Wallet code doesn’t scale well. All transactions that were ever relevant to the wallet are loaded into memory, all the time, and re-written every time the wallet is saved. This results in a simple on-disk format accessible to many kinds of apps, but has poor performance for heavy users. In time we’ll probably switch to a log structured wallet file format to solve this.
How likely is that to affect a production application on a large scale?
I was just wondering the same when try to update from PlayStore.
Generally, say for Windows, when it is updated, downloads the files and patches them. From size perspective, these are significantly small compared to its setup which is around 3.5 GB.
So why its not applicable for ANDROID apps? E.g. any update to WhatsApp is almost equivalent to its original setup file (~18 MB).
Although Play Store calls them updates, you actually download the whole Android app again. In a way, it's still an update because you do actually upgrade to a newer apk version but not quite the way you would've liked. It's taxing on your bandwidth but it's easy.
However, your app's settings (shared preferences) and data (SQLite databases or custom files) survive this update/install process which won't be the case if you manually uninstall & install the app's new version again.
In cases where the app's database schema has evolved between the two versions, Android notifies the app on startup that it wasn't a fresh install by calling a life cycle method onUpgrade() where the app has a chance to upgrade its data left over by the previous version.
When you compare this with Windows, both the OS and the update server are from Microsoft and they must have worked together to figure out what needs to be pushed (.dll, .ini, .sys etc.), update bundle's format/compression and security implications (some sort of encryption to prevent malware injection by any one intercepting the traffic).
No such standard update mechanism has been made available by Google for the Play Store see update and I believe so is the case with every other app store. Obviously, the developers can't roll out one on their own since the updates are handled by Google both at the device and server side.
But, the developers are certainly not unhappy about it. It's much more convenient to test the new apk, see it working and uploading the same rather than fiddling with what changes to push and breaking the app if you miss something. The bandwidth is cheap anyway.
I've just recently discovered that at Google I/O 2012 Google announced that they were working on a Smart Updates technology using some delta encoding algorithm. The idea was to compute the DIFF between two APKs (sort of like we do for text between two source code files), create a patch on the server-side and only send that over the wire.
This feature went live on Play Store later that year as reported by AndroidPolice and TechCrunch.
Developers, Google said at I/O, won’t have to do anything to enable
this feature and according to the folks over at Android Police, this
feature quietly went live late last night or early this morning.
You can see it in action in this video. Notice how the apps start installing once the progress bar hits just 40-50%. This is absolutely brilliant because not only this saves Google terabytes of bandwidth, its pure server-side approach means developers don't have to fiddle with anything. Perhaps, that's the reason it finds no mention on the android developers site and so takes time to get discovered.
With that said, my personal experience seems to coincide with yours. I see most of my app updates download almost the whole of the app. Maybe it's because I don't download very frequently. It's not unusual for me to skip several minor revisions and perhaps the app changes far too much to derive any size benefits out of the patch generated.
There is nothing like an "update" for an Android app. It is always a full app. It is called update, because it is a new version of the app currently installed in a device.
But when it is an "update" the whole app is not fully downloaded. For many years the Google Play downloads just parts of the app and patches the currently installed app with the difference. So in the case of 20MiB the Google Play can download just few megabytes to reconsctruct the new version in a phone. Google calls is Smart App Updates or something like that.
I am developing an app for IOS/Android/iPad that will be linked to a database. I would like the entire database to be downloaded to the user's device the first time the app is accessed and then updated every three months automatically. I was told by another developer that Apple may not allow an app to be downloaded in its entirety and that it may affect a user's storage capabilities. I was hoping to get some info on this from people who have worked with these issues.
UPDATE
Based on Seva's answer below, I have a follow-up question:
Will a user be able to download any content from the database? I see that they will not be able to update their database in this manner, but can they retrieve other content?
Thank you.
Both iOS and Android have both limitations on package size and way around those limitations.
On iOS, the packages over 20 MB are not downloaded over cellular data link; but people can get them over WiFi or wire (via a desktop computer with iTunes software). By making an overlarge package, you'll surely lose downloads.
On Android, the package size limit is 50 MB, but you can register additional APKs and download them as necessary (look it up).
On either platform you can ship the app without a database and on the first run, pop a "Please wait" window and download it over regular HTTP. Some apps that I know do exactly that.
The tricky part would be updating. Applications are not supposed to install code. That means - no updating itself. The proper channel for app updates is Google Play and iTunes, respectively. You're free to download and install an updated database anytime, though - as long as you code the necessary HTTP access.
I've implemented Android backup for my paid-application. I want to build an ad-supported version of the same app, and since they are using the same data I'd prefer to share the android backup between these two apps. How should I do?
EDIT
The refined question is whether it is possible to share the application backups on Google's servers.
My Answer: AFAIK it is not possible because Google will store the backups per package name, which must be unique per application.
Original Answer
I'm still not sure why you want to access the same data from both apps. Yes I understanding the upgrade path, but why not just copy the data over when the user gets the ad free one?
Anyway, your implementation of the BackupProvider will have to be responsible for managing the shared data. Now since you will have 2 versions of the provider (free + paid) they need to ensure they don't overwrite each other in the shared location (like the sdcard).
But even if you follow this approach Google is still going to maintain 2 separate copies of your users data, one per application (AFAIK this is determined by the package name of the app which must be unique)
We have an application, that can itself be downloaded for free, but works with paid, licensed data. Some users buy particular version of the data while others buy right to use latest data for some period of time. Now as the application evolves, it eventually stops supporting data older than some date. So obviously users who have those data licensed, but no license for newer data don't want to upgrade. But if we publish new version on the market, they would see it and if they upgrade, they will have trouble downgrading back to version that actually works for them.
So can we somehow instruct the market application not to offer upgrades for particular user or some hack to achieve that end?
We currently use mechanism completely independent on the market to sell and check licenses for the data, but could consider different mechanism (like the android in-app billing support or something) if it could help solving the problem.
The way I see it, you have two options to "disable" upgrades:
Use a different signing key - this will prevent installation without removal of the previous app, but upgrade notifications will still appear (I think)
Use a different package name - this will prevent upgrades since it is a completely separate app so far as the market is concerned, and also has the side-effect that old versions are still available for those users who are licensed for that data version.
The second option may be a better match since you can roll out upgrades if necessary for bug-fixes, but can also ensure that wholly new versions are not detected as an upgrade.
EDIT:
Totally agree that the above options are cumbersome and don't really solve the issue as-is.
As you mentioned however, you could use in-app billing, but given the nature of your requirements, you'd have to use unmanaged purchases which means you'll need some infrastructure to manage authorising purchases and preventing people from buying the same license too many times.
I'm guessing you've already got much of that infrastructure in place to handle distribution of the data though.
Can the data not contain a "format version" number at the start of the file?
Then you can program the app to read version 1 files, a new app needs more fields on the data source, so you create version 2 data, which adds extra fields, version 1 app see's the data needs a newer app, so tells the user to upgrade.
Version 2 app should know how to read version 1 files and version 2 files (perhaps create a reader Interface and implement loaders for the different versions of files.)
You'll have to handle the missing data in v1 / old files in the loader in the v2 app. The loading of older files is the nicest way for the customer as the app shouldn't just stop working after an upgrade.
If you keep a copy of each format's data you can quickly run tests to check the new version's loader can load each file correctly, plus if the app has a bug in there you won't have to fix several app versions, just the current one.
Ok.. I saw one of the posters suggest you have a way to read the old data.
First that's likely the best option but as you say your apps a mess.
You should invest some time in migrating your data reading/writing to an abstraction layer. The pain your having on a (likely less than 4 year old project) is only going to get worse.
Okay.. so here's how I've dealt with it in long lived apps..
Create a migration path.. Create a new class call Migrate.
In it have several functions to convert the version of the file from n to n-1
convert_1_to_2(fileName){check the version and upgrade data.)
convert_2_to_3(fileName)...
I suspect you have your old code, and you could write a method to convert one bit of data to the next..
When you add new features to the data, then you create a new convert.. No knowledge of the earlier ones would be needed, and everything would be nice and self contained.
You could even have sub migrations, so part way along the dev cycle, you could have convert_3a_to_3b.
Now... you could archive the original version of the data in case the user wants to go back.
If the data is accessed remotely, you could have the app include the version, or some hash of itself, when requesting it. And then filter the data provided based upon that information.
If you already have in-app purchasing and the infrastructure to support it, just poll for new data when the app is upgraded. If the user has purchased the license for current data, provide it. Otherwise just continue using the existing data.
I came up with an option that market will contain an installer that will download and install another .apk containing the core of the application locally.
We already have an installer dialog in the application for downloading the data and user has to enter it when using the application for the first time, so it can be made responsible for the application core too.
You can not definitely prevent users to download the new version of a app they already have. You can either register a new app or check the version and user data programatically.