I'm intending using Localytics (http://www.localytics.com) for an app which will be released on both iPhone and Android. My question is: Should I aim to use a separate app ID for the two platforms? I'd really like to just use one (so that all my analytics apply to both apps) but I notice that some things like "operating system version" just appear as a bit of a mess if I use the same ID for both.
There's nothing in their integration guide mentioning this - anyone have experience of this one way or the other?
I work on the Localytics SDK team and I'm happy to help.
While there is no technical reason you can't share a single key, we recommend keeping them separate. In addition to having a combined list of devices, operating systems, app versions, etc, your users likely behave differently on each platform. Using a single key will make it more difficult to see platform specific trends in your app usage.
Related
I am looking now into re-architecting a library based Android App, so that instead of providing each library's functionality at build time (limiting its expansion to me only), I would just provide a base App and an SDK that would allow any developer to independently write a plugin.
I couldn't find many ways of accomplishing this on Android (unlike .NET's Unity dependency injection framework which supports independent DLLs). What I found was:
APK based approach:
http://blog.raffaeu.com/archive/2015/05/31/android-plugin-application.aspx
Service based approach:
http://androidsrc.net/creating-android-app-plugin-architecture-tutorial/
My question is: Are there additional ways of accomplishing this? (note: ways that are legal from Google Play's ToS)
Also, in your opinion, which of the two approaches that I listed above is superior?
Generally, if an app will accept some sort of plugins from other developers, those plugins are distributed in the form of APK files, whether through the Play Store or through some other channel. Those plugins may need different permissions than yours, for example, and that can only be accomplished if they are first-class citizens on the Android device.
Hence, a plugin is merely some other app that interacts with yours through some documented and supported IPC mechanism. The big four Android components — activities, services, receivers, and providers — are all possibly relevant for a plugin. It really depends on what you want the plugin to do and what the plugin needs from your app to be able to do it. In the abstract, we cannot tell you which of those to use.
Personally, if I were going to do this sort of thing, I would write the base app plus at least three plugins. The act of "eating your own dog food" when writing those plugins will help guide you towards what IPC mechanisms are needed. Even if, in the end, you ship the plugins' functionality directly baked into the main app, having "real" plugins will help shape your SDK, your security model, etc.
First I am a java backend developer and are looking for clues in the right direction
Question is it possibly to create a app what third party developers could include in their app with minimum of effort .
Background: I have a numbers of potential customer what all have a existing app made from difference developers some in house others from extern developers
Now I want to offer the customer a extended feature of where app, and to avoid what the customers need a whole rewrite and cost of their app , is it some how possible what I could code a app what could be included in the existing app with a with a minimum of effort for the customer (its alright what i have to make a change to every different app)
and a side note can I somehow protect my part from being copy from whose who have to include the app/sdk
Any clue on technical papers are very appreciated
You can use
As you are good with java I suggest you to look into Xamarin as C# and Java are very similar
Or if You are Good with HTML and know a little bit of Native then you can Go for PhoneGap Cordova
Or if You are Good with Angular Js you can Go for IONIC framework, cool part is you can drag and drop to build UI
All this frameworks allow developers to write code for all plateform with minimum effort.
I am trying to develop my first Android app with the Google Realtime Multiplayer Gaming API. This will involve sending update messages to the peers as the game progresses. I would expect that down the line, as I make updates to my game in subsequent versions, some of the data may change and I would like to keep the messaging compatible between app versions. This is a common problem in other fields like networking and usually solved using solutions like TLVs or Google Protobufs. What is the recommended way to handle this in Android apps? Also, when a peer-to-peer connection is formed (when player joins room), do we have any way of knowing that app version the peer is using?
Thanks!
I also dont have a satisfing answer for this. Currently i wouldnt match versions that differ in that regard. To prevent that, it should be possible to use the variant bitmask in the autoMatchCriteria and reserve some bits to identify the version.
I am an app developer and I use Xcode to develop all my apps, but seeing in today's market a lot of people now have non apple devices. So I guess I'm wondering if there's an easy way to take my code for my apple apps and convert it to android format so I can submit to both markets?
Also does Android have their own version of "iAds"?
I agree with Ben, I was in the same boat a few months ago since the only mobile development I had done was on Xcode and I was trying to find ways to convert my existing project but instead I opted to just build a new version using Android Studio. As Ben said, even if you convert the iOS app, some of the UI and design patterns are different when comparing an iOS App to an Android App (for example iOS uses tableviews and the cells can have disclosure indicators while on Android you would need to use a list view and not use a disclosure indicator since it goes against the design patterns for Android). I would suggest taking a look at the Android documentation, specifically the recommended design patterns as that will help give you an idea of how much you would need to change to make your code work for Android.
You can use your iOS app's code as a guide to your Android app since even though the language is different, the overall structure would be pretty close.
You could share some parts of your android application with iOs using j2objc which converts java to objective-c. However anything that relies on the android framework will not work (the same would apply if you found something to convert it obj-c to java).
You could use something like Phonegap or Appcelerator. You would write code in javascript, HTML, CSS and then it would create iOS and android applications for you.
However there is some things that cannot be done using these technologies. I know that to get around this appcelerator allows you to create native modules.
You will never get an app on both platforms for 'free' there is always a cost involved whether it requires more work or you loose some features on one or both the platforms.
You need to work out how complex your application is going to be and what parts could be separated into a shared module/library. You would also need to consider how you are going to visually represent your app, it would be easier to come up with some middle ground between android and iOS than it would be to create iOS visuals on android or vice-versa.
If your making a game take a look at unity
I have an issue I would like some help with.
I have a product which I want to design mobile applications for all mobile platforms.
Now while design the whole layout and architecture of the system, I need a way to try and remove the need to redevelop or change the code for every platform.
For example, if i build all my apps for, android ,windows, BlackBerry, apple etc.
Now i release a new feature on my system, I will now have to go and update all the code for all of the mobile platforms.
Now my idea is to create a website which all the mobile devices talk to, which then talks to all of our products via the internet, This web site, centralizes all communication between the two ends.
Now the only solution to remove the needs for updates to all platforms is to then make a sort of thin client on each of the mobile devices, that then go to the website and display the websites content. Now with this, if we add a feature or fix a bug, we simply do so on the web server and in turn all of the mobile platforms will be updated already.
Now with this idea i already foresee potential problems like scaling the display for multiple clients, etc
Before I go and reinvent the wheel, I thought I would ask here if there is not already a way in which I can work around this design issue?
So basically I want to eliminate the need to make changes to all mobile platforms source code, and then publish an update which all users will have to download, and replace it with a central place of configuration where updates and changes can be made which will immediately affect all mobile platforms.
Thanks.
You thinking in correct direction, you should not maintain multiple code for same functionality as they need to be used in multiple platform. Rather they should have a think layer for each platform talking to same set of services which would be common across all the platform.
When you say scaling the display of multiple clients, If you have separate thin layer for each client and your complete architecture if SOA then ideally you should not have any problem.
Happy to discuss more.