I am working on a Unity game that uses AssetBundles and can be published to both iOS and Android devices. I also have three dev environments where I publish the builds for internal testing. To grab the files from the assetbundle server, I have five different base URLs to pull from, depending on the environment.
I want to externalize the base URL so that I don't have to keep making a new build for each environment. What would be the best practice to externalize config settings? Is there one?
If you want to be able to change the base URL without redeploying the project, I think your best shot is to use some intermediate URL.
You may require the bundle from some www.mygame.com/bundle/platform who will download the right file whenever needed.
You can also read the base URL from a classic file using Stream. You can then edit the file to change the URL without rebuilding the whole project.
Related
I have a .NET MAUI Project with a lot of assets (images) in the Resources\Images directory that shall be deployed to the Google Play Store. This means that the size of the generated aab package is way beyond the Google Play Store limit of 150MB.
(Message: Your App Bundle contains the following configurations where the initial install would exceed the maximum size of 150 MB...)
My current solution resizes the images to <= 150MB. I now saw that there is the possibility to generate separate files for the assets, which is called Play Feature Delivery.
From this sample project I get the following gradle file to create an install-time-package:
apply plugin: 'com.android.asset-pack'
assetPack {
packName = "install_time_asset_pack" // Directory name for the asset pack
dynamicDelivery {
deliveryType = "install-time" // delivery mode
}
}
My question is: Can this somehow be done with .NET MAUI? Is it possible to add some elements to the csproj-file to do this, just like for example for the keystore:
<PropertyGroup Condition="$(TargetFramework.Contains('-android')) and '$(Configuration)' == 'Release'">
<AndroidKeyStore>True</AndroidKeyStore>
<AndroidSigningKeyStore>..\myapp.keystore</AndroidSigningKeyStore>
<AndroidSigningKeyAlias>key</AndroidSigningKeyAlias>
<AndroidSigningKeyPass>SuperSecretPassword!</AndroidSigningKeyPass>
<AndroidSigningStorePass></AndroidSigningStorePass>
</PropertyGroup>
The characteristic of the app and the users makes it impossible to load the images at runtime, e.g. via https.
tl;dr I did not find any Maui answer at this time.
The best starting point looks like XamarinComponent/Android/GoogleAndroidVending.
HOWEVER that wraps a java library, and appears to use gradle, so TBD what knowledge is required to be able to build this, then adapt it for Maui.
The corresponding Xamarin.Forms doc is APK Expansion Files.
The Xamarin.Forms nuget source code and doc is at github XamarinComponents/Android/GoogleAndroidVending.
There is a Nuget link there, but that won't work in .Net Maui.
Until there is a Maui Nuget, it will be necessary to download the source code, and modify it. (If anyone does this, would be good to upload back to github. TBD where.)
App Startup is a bit different in .Net Maui, I did not investigate what might need to change.
In addition, there might be references to Xamarin namespaces that should change to Maui equivalents.
IMPORTANT: This c# code is a wrapper for a java library from Google. The project includes gradle references. TBD what the requirements are to build this.
If your APK is getting over 150Mb then I suspect Google and Apple (if you're making an iOS app) will be expecting you to host the image data in the cloud and pull it to the device on an 'as needed' basis so you're not clogging your users' device storage up unnecessarily. That type of static imagery should be stored in cache and not backed up (so you'll need to check if it exists and re-download if necessary).
We have an Android project where we maintain a single code base for different customers, what will be the fastest/most efficient way to compile for different customers every time? Few options I found and my questions:
writing scripts: to replace resources folder and edit app name, version, etc.
Using Android Library Projects It is gonna be quite impractical to separate current project as Library projects, I am thinking whether it is possible to save some settings and resources files as a Library project and just import different library projects for different compilation?
Storing settings and resources on a remote server Is it possible to store resource files and some app settings (xml, constants, etc) on a remote server, and download them and replace to the app when the user first launch the apk? Where will these files be stored?
Any other options you would suggest?
Android Studio provides a feature called "flavors" that allow you to quickly define different configurations from a single code base. I have just learned about this in the last couple of days, so I don't know a lot more than this.
The best way I've found is a post build script step. Use a default set of resources/assets for your main build. This is your default apk, use it for default testing. Save the unsigned apk this builds. Then for the customer specific APKs, open up the unsigned apk (its just a zip file), overwrite any overwritten files, then sign the new version.
This works fine so long as you don't need to change code for different customers. It also doesn't put any unneeded assets/resources in any build, so you don't leak info to one customer about your other customers by including their files.
If you do need to change code, the best way is to do a runtime check on a variable from a settings file. And overwrite the settings file the same way you do everything else.
As an added bonus, if you need to you can write a very fancy system that would allow the customer to upload his own files to override your defaults (including allowing them to override some of your settings), so you don't need to deal with a dozen change requests. That requires a lot more work though.
I've created an app which pulls data from a JSON file and displays it.
Now that app is specific for one sports team. I want to create the same app for 10 other teams.
Plus there will be an accompanying pro version of the app.
I'll be doing the same thing for the iOS version.
The only difference between the apps will be colors, logos and url of the data source.
I wanted to know if there was a better way to create apps. Instead of individually creating 40 different projects.
It will help me in updating the app as opposed to copy pasting the same code 40X.
Are there any special features available in eclipse and xcode to do that?
Thanks
I would simply swap out the resources for each team and rebuild the app.
For example, with Android, maintain an AndroidManifest.xml and a res/ subdirectory tree for each team. When it is time to build, simply copy over the resources into the project, overwriting the previous team.
I don't know of any existing tool to do this automatically, however.
Have you looked into using PhoneGap and just create a "mobile site" that detects the app that is connecting and adjusts the data/styles accordingly.
There's always the possibility of creating ONE app allowing the user to set the team preference upon first load, and swapping out resources programmatically.
With Titanium Studio you can write code using Javascript and it convert your code in native objective-c code, native android code, native html 5 code and soon also in windows phone code. It`s the best free cross platform IDE
Upon reviewing your responses, you seem to want a strategy to manage your resources. Since different OS has different resource requirements (screen-size, iOS 2x png for example). The most common strategy is to keep a separate resource structure and setup build target to copy/xcopy replace these image resources before build. Source control + an OSX build server would be most beneficial.
After creating these apps I've found the following way to be the most easiest way to create a similar app.
Android:
1. Select the project from the project explorer sidebar copy it and then paste it. Give it a new name.
Select the new project and then right click > Android Tools > Change Package Name.
Give it a new package name. Eclipse will give you an option to refactor the code, say yes.
Go to res/values and change all strings.
Change the icons and other images.
Go to src click the package and then refactor it. Give it the new package name.
Go to manifest file and rename any old names which might still be lingering.
I have some configuration I want to save it in my Android application and read it whenever I need , for instance, the server URL that it should try to access like that.
Is there any similar mechanism like web.config in ASP.NET available in Android?
A central configuration file that can be set up manually and then read by the application? Any help would be appreciated!
We use a .properties file in assets folder. It works out very well for us as we support multiple carriers with this, write to it (in case some values, sent from server, need to change. This is done at app start time, thus making our code configurable from server).
You can throw things like that into your strings.xml file. But, since you can't actually modify these values in real-time (since it's a distributed application rather than running on a server), throwing it into a constants class is quite acceptable.
Use Shared Preferences.
Here's a link Shared Preferences
You can use sq lite database files for it. You have a native API to read and write those and on top of that a command line tool.
If you want to create an XML file instead, then it's no different than any other xml file (unless you are thinking about the Shared Preferences, which use an xml format to save the data, but I believe it's not the best API for your application).
I was stumped on this too, but came across Managed Configurations in the Android documentation.
Managed configurations, previously known as application restrictions, allow the enterprise administrator to remotely specify settings for apps. This capability is particularly useful for enterprise-approved apps deployed to a managed profile.
It allows you to set a default value in case you rather not getting into the enterprise admistration business but leaves that option open for the future.
There is a caveat. This only works if your app is registered for EMM. Otherwise you will retrieve an empty map of restrictions.
We service multiple clients. One feature we want to offer is an android application which allows the client to custom brand the application (icons, logos, names, etc).
Here are a few stipulations.
Customers of clients will use this app.
You could be a customer of more than one client, but we cannot show the user any kind of list of clients.
Clients cannot share a single app.
The app must be able to look different per client, even though the functionality is the same
Yes, I know it's a PITA to build it this way, but our clients don't want customers of other clients to know they are also our client.
So, what is the best way to build an easily brandable application with as little strain on the developer's sanity as possible?
Keep a separate res/ folder for each version of the app. Give every icon, logo and String the same name but tailor the content for each client, and build a different .apk for each by simply dropping that res folder into the build. I don't think you can make custom qualifiers work for this and just make a single .apk - and this would in any case bundle every client's custom pictures and Strings in to everyone's application.
I would start by developing a script for a global re-name, since you'll need that anyway (can be done fairly simply with find, xargs and sed)
You'll need tools for making the customizations to resources, that could be the SDK & Eclipse plug-in
Perhaps you could create some kind of wizard extending the Eclipse plug-in.
Or with a lot of work but easier usage, you could do something stand alone that drives the necessary command line tools to build the generated package.
You can do what #Jems said or (presuming that the app comunicates with a server) put the "logic" on the server side.
The first time you run the application the server will send you the resources corresponding to your client that you store locally.
Problems with this approach: The first time you may have to download a load of stuff...
Advantages: You just have to change a properties string saying which is the server, or the login to the server to know what it has to send changing the layout without having to deploy another app with different resources.
It really depends if you want to support layout changes on server side.
Build time solution using gradle could be achieved with productFlavors feature, described in http://blog.robustastudio.com/mobile-development/android/building-multiple-editions-of-android-app-gradle/
Flavors (aka customer brands) could be defined in build.gradle file in the following way (different package names are here to deploy each branded apk as separate application):
productFlavors {
vanilla {
applicationId "com.example.multiflavorapp"
}
strawberry {
applicationId "com.example.multiflavorapp.strawberry"
}
}
Specific android resources for brand could be then placed (instead of src/main/res directory) into src/vanilla/res or src/strawberry/res directories (in this case vanilla and strawberry are the brands). Please be aware that using productFlavors feature, gradle does no merging of assets, only simple replacing files without any knowledge about specific res subdirectories.
During building proces gradle creates build variants as combination of build type (debug,release) and productFlavor, more at http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Type-Product-Flavor-Build-Variant.