We have an app, that is synchronizing with remote DB, and all users can modify this db. More over, each user has some data private to it, which is synchronized only between this users devices and not with other devices.
So, what are the best practices for automation testing of such app?
How can I see it:
We need at least 2 devices, to make changes on first devices and finding this changes become visible on second devices. At least, this the most high level tests that i do by hands. There are also two different cases, when those 2 "devices" belongs to one user (I use users Google account to differentiate between users) and to different users...
How this multiuser environment can be automated for tests?
You are going to have to probably do something less than ideal to test this, either create a special test build that allows you to override the account you are in (letting you jump between two) or build a way to have different databases for different tests that are in the state you need for any given user (e.g. by having a different endpoint for your application to hit for each test).
Without seeing your code these are the most general ideas, it might be a way pops up if i knew more but sadly I do not have access to that information.
Related
I'm currently working on a project that is going to have over 100 android devices used and the users of each device will also change on a daily bases.
What we want to achieve is that the user is allowed to open only 1 or 2 of the apps on the device. Meanwhile, everything else should be forbidden.
I've seen that G suite offers app whitelisting, but that doesn't really seem like the right use case and also it would cost more than 500$ a month to maintain. Also, the apps that will be on those devices will not be published on play store and will be directly installed via apk.
Thanks in advance!
Have you checked UserStatsManager class, you need to check which application is foreground and then you can display your own activity if it's not the intended one.
Two Part Question:
How do I do this for a mostly offline app (high level)?
Is it against policy or an expected / common practice?
The app in question, does not specifically require internet / store access to run. It is a free app, but requires in-app purchases to be useful.
Reasoning:
Basically, I do not want users on a version of the app that is too far out of date (say more than 2 or 3 versions, date dependent or both). The reasons are: The app will have regular reference material updates. I am also concerned that if security exploits are discovered, I have the ability to force the versions with a known exploit out of service. Is this a common practice to enforce version control on a mostly offline app and what is the high level model for doing this? Is it even an acceptable practice for Google Play Apps or is it on the fringe of Google's policies?
This is reasonably common practice, and not against policy. It is less common with mostly offline apps. It is most common games with a significant server component, as it is a hard maintenance burden to keep a server up to date so it works with all previous versions of the app. It does irritate users, especially ones who are often offline, and don't like the time or cost to download updates, so you may get more uninstalls.
As far as your first question, in a mostly offline app there are two good designs
The first design is time/date based. If you know your app has release cycles of a new version roughly every month say, have the app stop working after 3 months. This puts a ceiling on how old the app can be. This is easiest to code, and works best for completely offline users.
The second option is:
Make your app phone home to a server to check the required version whenever it is online.
Make the app check how long it has been since it has phoned home, and refuse to work after a certain length of time has elapsed (say a week)
For even better user experience, display to the user how long they have before they need to go online (Similar to Spotify offline mode, if you have ever used that)
This second option lets the user know exactly what is going on. In the case of a really bad security flaw, it also allows you to force an update more quickly. It is slightly harder to code, but not that difficult.
You can have an API which will check the app current version and if it's older than the latest version on the store you can enable a force update dialog asking the user to download the latest release from the store. This usually happens on the splash screen when the user opens the app.
Not sure if this is the right forum and struggling to articulate this questions but here goes:
We have a process in place where we regularly release testflight app builds in order to test new functionality and fixes in our app. We always point these builds at our production environment (API’s, databases, etc). This causes us some issues like:
We are regularly trying to test stuff which has not yet been released to production (i.e. backend stuff may have not been updated yet)
When we do move code from our backend test environment to our production environment it has potentially not been tested as the app never points there.
We dont see what our real production users see as we are always on more advanced builds.
I am sure there are a number of ways we could do this a lot better but a key requirement we have going forward is to be able to release versions of our app which point to our test environment so we can correctly test things end-to-end to help alleviate the above issues. At the same time we also need versions of our app pointing at production as we use the app ourselves day to day.
The two obvious choices that I can come up with are:
Option 1 - Have separate test and production apps
By this I mean we have two apps released with two separate bundle id’s and names (like app_test and app_prod). You can then load both of these apps on your phone at the same time.
Option 2 - Same app built to either point at test or prod
This is basically where I would release the same app pointing at either production or test. You can only have one or the other on your phone at any one time.
Option 1 feels like the right thing to do but I have a number of issues with it:
The configuration of push and provisioning certificates will be more complicated
Inbound push notifications will be hard to understand and debug on phones if you have the two apps running
We would need to either submit a second app to app stores or we will need to use a third party release tool like hockeyapp or whatever.
Our semi automated build process would need reworking to support multiple bundle ids and stuff
Option 2 on the other hand presents itself with problems too:
You can only have test or production apps on a single device at any one time. This implies we would need to get more devices to test from
There is a risk of releasing an app pointing to test environments to our production users.
I guess a 3rd option would be to have the ability to reconfigure the app to use either environment (by way of a hidden dev menu or something). This concerns us in regards to caching settings but maybe that could be worked around. I guess it also means we could only run one version of the app on a device at any one time.
Anyway, this is quite an open question for advice. I am really keen to hear what other people are doing when it comes to testing apps. I have read up a bit on this and spoken to a number of people to get input (which is what leads me to the above two options) but would appreciate more input and advice. How do you solve this problem? Maybe I am just approaching this from the completely wrong angle!
I need to increase the security of my android app. Actually my android app. will not be for Google play Store (which provides some licensing options to protect your app.) it will be used for some local companies that used the same app (Desktop app). However, I want to support two versions for my app. which are:
Demo version: for testing aims (after the given period end, the app will stopped!)
Actual version: this if the user want to pay for the app.
What I need:
To increase the security of my app. from installing it another time or on another device for the same user!
For my code I used ProGuard which is a tool provided by Android that lets you obfuscate (make harder to read) your code during packaging. cause there are many reverse-engineering application that used for unpacking the compiled code and viewing the source code (actually I tried some of them and its really amazing to restore the sourse code from .apk!) ..
I think to use the MAC address of each device the app. installed on and then store it into internal database and generate a number form it (in somehow), then ask user enters it (which I the one who knows this number and provider for it) if it is true, the app run else not. But, it's just idea I do not know how this can happen or even from where I can start or even also if that will help!
I tried also SharedPreferences But this does not help!
Actually I do not need for external database on server to read the username or the password for eligible users for app. I need to do that by my app. itself!
In sum please,
How can I protect my app from installing many times for same user or continuing using after testing period ends, etc. (I mean make it more secure)!
any ideas, any suggestions, any useful examples or sites are also desirable.
Sorry for this long question,
Use case:
We have a container App which comes without the needed content preinstalled.
Only after installing the App, users choose which items they want to install. The items here are "city packs", that is data for rendering maps, routing offline etc.
It would be very attractive for several reasons to be able to create Appstore entries for specific cities. However we don't want to get into a mess by really duplicating the App (maintenance overhead, fragmentation, potentiall confusing for users).
That's why I was thinking about something like this:
The additional Appstore entries install a minimal App (I'll name it client App) which essentially just launches the main App with some parameters. On Android that should be possible with Intents, on iOS with custom URL schemes.
Since I don't know of any App using that approach, I wonder if they exist and if it's possible.
There are however 2 potential issues I see with that approach:
If the main App isn't installed when one of the client Apps wants to launch it, the client App can still open the App page in the Appstore. At that point however the client App will lose control and I guess will not be able to have the main App launched with a parameter set. Is that correct?
Would Apple accept such an App?
I'm not sure if what you want to do is possible, but with my experience with Apple it is unlikely that they'd be happy with many different parts of the app being separate... I may be wrong, but that's how I think it'll go...
Have you thought about using in-app purchases? Even if the packs are free i'm sure you can set the cost to 0 and have the data download then?