Looking for a suggestion.
I have uploaded an app on playstore. In that app, I have few templates of questionnaire (xml files - stored in resources).
Client modifies some of the templates once in a month or two.
When client modifies the template, I need to sign and upload APK again.
Is there any way out to upload only the template resources and enable app to read them or something?
Like for media players, themes are uploaded as different package or application, but once downloaded they are part of MediaPlayer.
Thank you!
Currently, as you guessed, the only practical approach is to upload a new APK every time there is new content.
Two ways to solve this:
1. The elegant solution:
If you can re-architect your app to communicate with a web service, you can store your templates there. Once a user installs and runs your app, you can have the app contact the service, authenticate if needed, and download the templates. This can be done once on login or every time the app is run - purely a design decision.
The minimum functionality you need from a web service is an online database. One example is Parse, which is going to discontinue service soon. Another is Firebase, which is free and fairly easy to use. You could store your XML templates in Firebase and have your app download them as needed.
This approach gives the developer control of the template content.
2. The super hacky way
Designate some directory in External Storage (this is important) to store these template files in, and have your app periodically scan this directory for templates to use. When there is a new or updated template, the user downloads the template and then copies it to that specific directory.
Obviously, this plan is full of holes - anything can go wrong here: users not knowing how or where to copy what, misformatted files, etc. And your userbase can have wildly different collections of templates and if something goes wrong, you won't know which templates a particular user has.
So there's the easy and the hard way. Obviously, I recommend the latter, if only for stability and sanity reasons...
Related
I have a rhythm game that I am almost finished working on but have hit a bit of a snag. We have an in-app store where users can purchase additional "song packs" for money. These packs contain song files (text asset), song banner images (png) and the songs themselves (mp3). This data is stored on our server, and the Unity app communicates with the server after a successful purchase is made. The server script validates the purchase via the Google Play Purchasing API (with the purchase token) and then if its valid, downloads the zip file of the data and extracts it into the Unity app. This part is working great.
However, I seem to not understand in what format I need to have the content or where exactly to put it. Furthermore, my game makes use of Addressables tags to load data between scenes. This works, but I am not sure how exactly I would handle this for downloadable content. Can I create new addressable tags via the API at runtime? I want to be able to add additional downloadable content to the app without needing to update the base games Addressable information. Is this even possible?
My main questions are:
How do I deliver my downloadable content? Do I need to package it in some type of Asset Bundle? Would this keep the import settings like audio compression that I set in Unity?
What folder should I extract the downloaded content on Android? StreamingAssets?
Can I create Addressable tags at runtime? Is this possible and is this a good idea?
Thank you for the help!
I would rather only code one core URL where your app when it is started can find and download the Addressables content catalogue! This allows you to fully add and remove entire Addressables, groups, tags etc without ever needing to rebuild your app. You could e.g. give each of your root objects a certain label (the same for all) then you can basically load the catalog and show the user all existing tagged results without immediately loading them .. see LoadContentCatalogAsync
How do I deliver my downloadable content
You need to build your Addressables via the group window and then simply copy the entire content catalog (JSON and hash) and the resulting individual Addressables (usually one per group) onto your server where your app can access and download them.
This way you can basically even have two complete separate Unity projects, one for building the content, one for the actual app.
You only need to be sure that both projects have the same code base used by your addressables and that all required dependencies are either in the projects or within the Addressables.
See Loading from Multiple Projects
I'm developing an app which stores items for the user, and the user has an option to sync with Google Drive. Each item consists of text and image.
My current method is to save a .json and .jpg file for each item internally to the device, and then once onConnected is called from Drive APIs, upload these files to the user's APP folder in Google Drive. Similar with deletion, I would create a flag that an item with name 'foo' has been deleted, then try to see if the files 'foo.jpg' and 'foo.json' exists in Drive, and delete accordingly.
This works for me now, but often I get the app to crash because of googleApiClient errors and I realize that this is not an efficient method. So what I'm wondering is whether any of you guys know a more efficient method to do this?
In the ideal world I would love to have something like this: I save the files for each item to the device internally, and a library tracks these and sync Drive accordingly.
Thanks for advice!
Based on the fact that you are referring to 'onConnected' and 'googleApiClient', I assume that you're using GDAA not the REST Api.
You should re-think the idea of using file names when dealing with GooDrive. They are not unique in GooDrive and the GDAA's latency will sooner or later cause a problem with presence of multiple files with the same name, created by ubiquitous construct:
if file.name not exist
create file.name
The fact that you use APP folder makes debugging even harder since you don't have feedback by looking at the http://drive.google.com.
You should refer to your files by the DriveId (if using only a single Android device) or by the ResourceId (if you intent to send/broadcast the IDs to a different device/app). And if you decide to use the ResourceId, make sure you handle the latency issues caused by delayed GDAA's promotion of objects to the Drive.
This certainly does not fully cover your question, but it is too broad to answer correctly anyway.
Good Luck
I am new to this. I have the Android SDK installed with Eclipse. I can work with basic activities and layouts.
I am looking to write this Android application that will;
1) Allow users to sign-in using a pre-allocated password.
2) Login and change the password.
3) Every time the user opens the app, he downloads a CSV file from a server to the SD card.
4) The app parses from the file and displays them on several activities and small frames inside the app.
Think of it as an informational application. But, I'd like to add some intelligence on top of it after I get this done.
I have read many articles and topics but none of them give me a specific approach to do this faster. I have very little time for development.
If there's a similar application that you're familiar with, I'd like to take a look at the code.
I want to know exactly (the code) on how the communication between the app and a linux based server on the web needs to be established. Right now, there's only a CSV file (or an EXCEL file - which one's better to parse? How to decide?) there.
Also, when the CSV file is up to date, I wouldn't want it to download the file again. How to prevent it?
As I said, I am new - so please be patient.
Thanks
If you are new to this and want to develop something fast, why do it the hardest way, in java? There are so many easy toolkits out there, e.g. RFO.Basic, you will be amazed how much you can achieve, fast, that way.
(You asked several questions) Easiest to parse? If you don't have Excel installed on your Android device, the CSV is of course easier to parse, needing only text tools. However, if you have a choice of formats, why not use XML? If you have never worked with XML, there is a little learning curve, but there are lots of tutorials on the web. After that, you'll never want to go back to CSV.
Your last question: how to prevent download of unchanged file? Is this about a big file? In that case start with quickly downloading the hash (checksum) of the file, so that the client can decide if the file has changed.
Within my Android app that is available via Google Play, I want to offer additional items that can be bought via in-app billing.
The kind of items I want to offer is media content such as graphics and sounds, which would normally go into the res folder of the app.
The problem is that these resources must be protected, of course. In its documentation, Google suggests not to store the content inside of the application package but to obtain a key after the item was bought and then send the key to a remote server where the key is checked and, if successful, the graphics/sounds offered for download to the app.
This sounds good, from the security perspective. But if I do this, I can't use the content as easily as resources can be accessed normally. If the user can get additional background PNGs, for example, I can't use R.drawable.new_background but have to decode the bitmap programatically, right?
So are there any alternatives or best practices for downloading additional media content via in-app billing?
I would say, as everyone who is determined enough can reverse-engineer the code, anyway, why not just store the content inside of the app but do strong checks if the user might use that content at all.
The answer depends somewhat on your specific concerns, which, from your question, might be either 1 or 2 below:
1) I'm concerned that someone will be able to use my resource within my app without paying, or
2) I'm concerned that a user (either one who has paid, or one who has not paid) will remove my resources and use them outside my app.
Another possibility, that does not seem to be indicated by your question (but which others have attempted to address) would be:
3) I'm concerned about my initial APK download being too large due to downloading a large number of resources, only some of which they user will decide to use.
If your only concern is item 1, then you can just store your resources as you normally would, but inside your app, refuse to load / use any resource for which you have not yet received an in-app payment. This is certainly the simplest approach.
If your concern is item 2, then you can just include with your APK an encrypted binary archive in the raw folder, and decode a specific resource from it whenever that resource is authorized (e.g., by payment) for use by the app. As others have noted, this is not really a big deal in terms of processor load, and it does provide some protection from casual theft. Of course, there is always copyright law if you're dealing with one of those "creative plagiarist" oxymorons who breaks your encryption and steals your resources anyway.
If your concern is item 3, then you'll need an external server from which your items can be retrieved.
Google App Engine is a popular choice for hosting when implementing this kind of storage outside the app. You would want to just cache any purchased /downloaded resources in an encrypted archive in your app's own external files folder (as returned by getExternalFilesDir()), then read and decrypt it as in item 2, above. Such files will be automatically deleted when your app is uninstalled.
One of obvious reasons for not storing additional content in the app is your app's app download size. If you are offering audio as additional content it can drammatically increase the size of your application. And users care about it. Besides it makes it easier to publish additional content, since you can do it via your server side/developer console without the need to publish app update. Moreover, if you want to provide high quality graphics, you will be able to serve appropriate version of the image directly to the device without the need of storing all density/screen size versions.
If you are concerned about security you can always use encryption and signatures to access resources and make attackers life much harder by properly obfuscating your code (or even moving security/decryption related code to native side, which will make it faster as well).
Yes, that would create a drawback that you will have to decode them programmatically and there is nothing to do about it. I honestly don't see why it is so big of a deal, on contrary, I think it's quite convenient that you will have more data driven access to resources.
As a summary I dont really think there are any standards for doing this and it depends on your app and content type. If you offer a fixed amout of 5-10 images, then there it is perfectly fine to keep them locally, if it is richer content, more items, heavier resources, then client-server would suit you more.
One solution would definitely be the following approach featuring two apps that share the same user ID. But this is not as elegant as in-app purchases and a bit hacky, obviously.
Create two apps with the same android:sharedUserId in AndroidManifest.xml
Store the paid content in the second app, that is a library app from now on and only contains those images (apart from necessary folders and manifest)
Sign both APKs with the same key
Offer the first app for free, as usual, and make the second app a paid one
In the free app, use the PackageManager to check if the second APK is installed
If yes, use createPackageContext() to create a Context for the second app which is then used to access the second app's resources from the first app
Google Play offers extension packs that can be purchased. These are large extensions that can be downloaded if purchased, and are separate from your app. This is one possibility.
http://developer.android.com/google/play/expansion-files.html
Depending on how secure you want it, and the size of the media, you can encrypt the media with a key, and store it with your app. It will be downloaded and installed with the app, but inaccessible. When the in-app purchase is complete, you can decrypt the contents and offer it to the user. You can either store the key in the source code with the app to decrypt it, or you can verify the purchase on your own server and retrieve the key from your server.
this should be an easy one for whoever published Android Apps before...
Here is my situation:
I'm trying to develop a "city guide" app and I was wondering if my idea of working with .XML files to structure my data (the client provided a .PDF file with pictures, address, tel. no, websites, opening hours of the different destinations) is the best way to go.
I was hoping to be able to write this app as an "interpreter" for this type of .XML and then easily include other cities or destinations in a city by updating that input XML file.
So this is not a technical question, I know how to pull this off, the question is if this is a good way to go? How do you keep an app easily up to date? Would a altered XML trigger a Market wide update notification ?
My research lead me to believe that this is a comfortable way to update a published Android Market app (prior to this inquiry I consulted:
http://developer.android.com/guide/publishing/publishing.html
All helpful hints and suggestions will be greatly appreciated.
Regards,
Veo.
Once I developed such kind of an app that had to contain the whole information in itself. I structured it in SQLite database that I was shipping along with the application. The file was not directly readable (or at least easy to read) from the assets folder, but every time when the file was altered I copied the sqlite file to the application storage and used it as ordinary application database. The cool thing is that this way I did not have to pay for the parsing of xml every time the application ran.
Several notes here:
My database grew too big and I had to split it in files of 1MB, because this is the limit for a file in the asset folder. For more info see here:
The database update mechanism with the database version still worked well.
When you create the database manually you need to take into account that Android expects one system table to exist in it (it is automatically created if the database is created in Android code). Basically see this answer here for more info on that.