I have an iOS app builded on Parse. I use push notification so I use the Installation table. My problem is that, when I use the same user account on two different devices (two different iPhones), there is still only one Installation entry in the table. My thinking is that there should be one entry per device, as each will have its own token?
Do you know if there should be 1 Installation entry per device OR 1 per user account?
According to "Managing Push Subscriptions with Installation Objects" when a device registers for push notifications via the client SDK, the push service works behind the scenes to manage the device’s subscriptions.
This subscription you can view and modify through “Installation”
objects, each of which corresponds to an installation of your app on a
device.
Installation objects are automatically created and modified when SDK push methods like subscribeToChannel and unsubscribeFromChannel are called, and are fetched by the getSubscribedChannels SDK method.
I would also want to comment that looking at my own tables on Parse I have a new row in Installation table for every new version (appVersion) of my app
See this link for an explanation of how the Installation class works by Héctor Ramos from the Parse team.
This gist of it is:
The Installation class contains objects that are just that - unique
installations of your app. When you delete the app from the phone,
then reinstall it, this corresponds to a new installation. If the app
is restored from iCloud, though, the same Installation object will be
used.
You will probably want to track IAP data in the User object instead,
then link users to their installations. A user can have more than one
installation, if they install the app on an iPhone and iPad, or if
your app is available for Android, too.
Related
Firebase Analytics first_open event sends a parameter previous_first_open_count.
it starts with value "0" (on lifetime first install / new user).
and subsequently 1,2,3 .. etc. increments by "1" each time I remove, re-install the app.
Can someone share how the SDK manages to persist the information how often user installed the app (basically triggered first_open) in the past.. AFAIK, once the app is removed, all the app data is deleted.. even the app_instance_id is regenerated each time I remove, re-install the app...
will appreciate to know for both Android and iOS
Actually cannot find any documentation about event_param: previous_first_open_count..
When previous_first_open_count = 0, does it means that user installed application only?
Or does it mean, that user have installed and opened app for the first time?
As per the definition ’first_open’ (https://support.google.com/firebase/answer/9234069?hl=en&visit_id=637466094047451258-3073953155&rd=1):
the first time a user launches an app after installing or re-installing it
This event is not triggered when a user downloads the app onto a device, but instead when he or she first uses it. To see raw download numbers, look in Google Play Developer Console or in iTunesConnect.
Supports measuring first_open conversions for users who accept Apple's iOS 14 app-tracking prompt.
I have a client for whom I have made three apps for different regions (App 1, App2, App3).
Now the client changed his strategy and instead of having a different brand for every region he wants just one global brand which also means one app. He obviously doesn't want to lose the users of the three old apps in the process so my question is: can I somehow merge all these apps into one on Google Play and Apple Store?
I couldn't find sufficient information anywhere. All I could think of was to update all three with a new package but that would mean that three apps (now with the same name and same everything) remain in the stores, which would probably result in deletion.
Is there any way to do this?
you should tell all the users of 3 applications by notification that they need to download new application and their data will be transferred into the new application.
While Prashant Jaiswal has already answered it, let me elaborate it a bit.
Step-1
Provide an update to each of your 3 apps that shows an overlay with a message saying that We have a brand new version the app and current version of the app is going to be obsolete. Please install the new app from playstore
Step-2
If there are any local databases associated with your app, then make a provision to update all the user data to server as a backup which they can retrieve again from the new app.
Step-3
If your app has social media login associated with your app, then it will no longer be continued, since changing the package name will result in creation of new app, so you have to make necessary changes in your server to handle the social media login.
step-4
Make the provision to accommodate the changes of step-1 to step-3 in your existing apps so that the migration can be taken place, and once user clicks on the install new version, begin your migration process before redirecting user to the play store.
step-5
Then use this link for Android Implicit intent to uninstall application? to uninstall your existing apps once the new app is downloaded and follow something similar for iOS part.
final step
All the above steps I mentioned by considering the general app design, there might be few more things that you have to consider based on the complexity of your app and its interaction with the servers
Just so that you know, you can not merge the three apps directly at
playstore. The only way to merge the apps is create a merged app and
redirect the users.
I am new to cordova app development and I am not sure how to approach this application workflow.
The workflow is that:
1. user download and installs the app
2. he ca use basic feature without registration
During this time (unregistered user with app installed) on backend we have to track the user activity and in case he register using email to upgrade his profile and keep his previous activity.
A solution to this will be to generate a user GUID on mobile when user first install the app. Send it to backend and use this as a future reference of the user.
Where can I store this GUID to be reliable and not to be cleared by the browser/application cache. If user clears the application data I would like the GUID to stay.
It will be great if this setting will stay if user upgrade the app or uninstall and reinstall later.
V Best,
Radu
You shouldn't storage data in a device when the user uninstall it, but if you still want it, check this plugin:
https://github.com/apache/cordova-plugin-file
You can save in different locations, even in the external storage of the device, which doesn't get deleted when the app is unistalled
Cordova unique device id plugin generate a UUID that remains the same after app uninstall and works on iOS and Android.
On iOS it generates a UUID and store it in the Keychain.
On Android it concatenates various IDs unique to the device but needs the android.permission.READ_PHONE_STATE permission.
Our contracted Android developer provided us with the source code of the work performed for us, as per our contract. After the contract finished, the developer became busy and is now not reachable. We are moving to another developer to maintain the application. However, we do not have the first developer's keystore so the application is not allowing us to update it.
Is there anyway for us to maintain this application if we cannot get ahold of the original developer? We have lots of customers who have the app with data they have generated, and they need our updates.
If you have push notification feature in your old App then you can send a push to all your user that there is another updated version is available.
And Just upload updated version with different package name. And even you can send play store link in that push message as well. Most of people use this technique and they got success to move all user from old app to new.
No you can't update your app on the store without the published keystore.
You can publish the app with another name and keystore (a new app so with a different package name) but you can't update it.
Is there a way to pass a custom argument to android market (or any other way) so my app receives the argument after it gets installed (and run for the first time).
Let me explain.
Start an intent with argument1="Hello world1" (custom argument
every
time)
Install the app from android market.
Open the app for the first time.
App shows the msg "Hello world1"
Any case will do, not just intent to android market.
Most of the time the app will be installed via Barcode scanner with a binded http schema. So a browser workaround is possible too, HTML5 Client Side Storage, (store argument to browser and get it from there the first time my app runs)
Update
A solution would be to create a cookie,or something to the browser and then access it from the application i installed. Is that possible? If so can you provide some information about that? Can browsers share data with applications?
You can publish a link like that
http://market.android.com/details?id=your.package.name&referrer=your_referrer_parameter
After user clicks this link and installs the application your broadcast receiver will receive a broadcast com.android.vending.INSTALL_REFERRER with "your_referrer_parameter" value.
More info:
http://code.google.com/mobile/analytics/docs/android/#android-market-tracking
Get referrer after installing app from Android Market
Get Android Google Analytics referrer tag
AFAIK what you're asking is not possible. The market only delivers the APK files to devices. However depending on what exactly you want to do there are probably many different work arounds.
Here are a couple thoughts:
If you want the market to deliver a custom argument that is unique for every user, then why not have your app connect to a server on the initial run and download that argument? Even if the market could provide the argument it would have to get it from you and you would presumably have to setup a server to provide the market with the argument.
If you simply want the app to know wether or not it is running for the first time you can do that using a SharedPreference. Query if a preference like hasAppRunBefore exists and if it doesn't then you know the app is running for the first time since install. Then set the hasAppRunBefore variable to some value indicating that it has run before. This implementation will allow users to uninstall the app and reinstall it and after each reinstall the app will run for the first time again.
Another option is a combination of the first two. You can have the app connect to your server and provide the server with the device's UUID then the server can check if its seen that UUID before. If it hasn't it provides the argument otherwise it doesn't.
If you truly need each APK to be different for each device you can setup a server that when a download request is received it compiles a new APK and provides a link to download that APK. That will allow you to generate a new and unique APK for each download. This will however require you to distribute the APK yourself as the Android Market doesn't currently provide this functionality.
I would go ahead and have the website that redirects to the market also push a file to the client. the file can be named something like "yourapp.info" and contain the data you need. Once your app starts, it can search the SD card (it should reside in a couple of well known directories, aka /sdcard/Downloads ) and read that file. There are no access restrictions on the sdcard.
Regarding a Cookie in the browser: I'm not sure that you could access the cookie from just any other app - (check this: blog.watchfire.com/files/advisory-android-browser.pdf - it's not possible to access the cookies) so I think that route will be closed.