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
Related
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...
I'm using the Google Drive Android API (yes I know its still in developer preview), to create a file on Drive that can persist data across all of a user's devices.
https://developers.google.com/drive/android/create-file
So, use the app on your phone:
-Check that the file exists (filter by filename and not in trash)
--If exists then read and update local sqlite with data
--If not exists then create new file, and write data from sqlite. Then request sync.
-When user changes data, open file again, write contents and commit/sync.
I'm finding situations when testing where I run on my phone, and then on my tablet, and there happens to be multiple files created of the same name and my app gets confused when opening. I'm guessing there were duplicates because there was a delay in the sync and the 2nd device didn't find the existing file so created a new one.
So, now I'm thinking, I pull in all files with that name (not marked trash) and merge them, then mark trash on all but one of them and call that the current. This will leave many files in the trash as time passes.
Couple of questions:
Is there anyway to create a file with a unique name, or pull by some unique handle. The duplicates are making things a hassle to use this Drive product.
Is there anyway to delete a file, not mark for trash, but actually delete. After a merge, I don't want to leave hundreds of files marked for trash on someones drive after months of use.
Am I missing something obvious here? All I want to do is continually overwrite a file by the last device to save data and call that the master copy. Then let other devices know that they should refresh when they run. Right now, I have a network tool app, but I'm also creating a game and was hoping to leverage this same mechanism to save/persist game state across devices....at this point I'm not so confident that Drive is the proper means.
As you've discovered title's are not unique in Drive. However, each item in Drive does have a unique identifier. In the Android API, the DriveId is the representation of this. (In the web API its the resource id).
Once you create the file, you can save the DriveId in local preferences so that next time you can just look it up by the ID. This will guarantee that you will always have the same file on the same device.
On other devices, you can first do a query by title to determine if it exists already, and then save off the DriveId if it does.
Google Play Cloud Save is designed for lightweight persisting of save state across multiple devices including conflict resolution and was built originally for games (although any app can use it). This seems like a more likely fit for what you want to do than trying to work with the full file system approach that is Google Drive.
I am in process of designing an Android App :a poetry application, which would
a. display the poetry
b. audio controls - start, stop, restart, move for poetry
There are currently collection of 25 poems and it may update in future.
One way is to
Approach 1. Make a static app with all available content and update the app regulary with newer contents
Advantage: Easy to develop as everything is static
Disadvantage: App would be heavy as it would contain lot of content.
Approach 2 Is it possible to put content seperately from the app,ex. app is installed and the content is placed on external storage memory. Using this mechanism, everytime there is a update, the content can be replaced with new contents (approach 2 = a very light weight player capable of showing content (may be in form of image) and audio capabilities + a separate location where content (images+mp3) are placed)
Approach 3. Make a hybrid app, as the user request for a content , the content is downloaded at run time and played using android audio capabilites.
Approach 4. Make pure HTML5 based web app.
Is there any other possibility ? Which option is more beneficial from user experience point of view.
Many thanks in advance
I would go with Approach 2,5, it is a mix of Approach 2 and Approach 3 where you save the downloaded file to a database so you do not download the same file multiple times and then play it.
Some clarification, as I understood Approach 2 would only have more poems if there was a Google Play update and Approach 3 was streaming. Using Approach 2,5 you will get the storage from Approach 2 and the playback from Approach 3.
Update: The term I was looking for was to synchronize data. Approach 2,5 is really just a way to download for instance a JSON and parse it then download the files and put it in a database where the app later can access it. With this approach the user need not update the app and if you want to remove a poem that is also possible.
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.
We have a mobile workforce using Android Galaxy tabs and use the MobiControl MDM product to sync detailed briefing files to and from the devices on a constant basis.
Rather than having the user search through a sea of irrelevant briefs in order to find the one they want, and to provide a nicer more activity specific UI, I would like to create an app which allows a user to tap a client from a list and then show links to the relevant files plus custom content such as recent news and summaries of activity.
I started to create locally stored HTML files (saved on the internal sdcard) with the idea of creating an app to access them using webviewer but have ran into a few problems...
1) What is the best way to access files that are stored on the sdcard using webviewer? loadData? string?
2) Although the files will be stored in client specific folders, the file names will change on a ongoing basis and these ever changing file names should be the titles of the links to allow the user to identify what they need.
Still very much at the preliminary stages of thinking and r&d so suggestions on the best route to take to achieve my goal is very much appreciated.
Ad
1) What is the best way to access files that are stored on the sdcard using webviewer? loadData? string?
loadUrl() should work.
BTW, your item "2)" is not a question.