licensing.init("google") and device checks?

Solar2D Android
#1

Have been looking at http://www.coronalabs.com/blog/2013/03/26/androidizing-your-mobile-app/#comment-38712 

Re the code like below you have to place in main.lua:

  local licensing = require( "licensing" )   licensing.init( "google" )

Q1 - I assume the normal practice is to have one build (re code) only and use this directly to build for both say IOS and Android?

Q2 - This being the case, I assume you have to put “am I on Android” type checks before hitting the code “licensing.init( “google” )” etc, else it would through an error?

Q3 - Is there a sample app somewhere that shows a simple hello world type app that has code ready to go for both IOS and Android (e.g. google play) that I could look at.  i.e. to see where there are “is this an xx device” type check certain code.  

#2

Hi there,

Q1 - Yes, your goal should be to have one code base that you can build for both iOS and Android without having to make any changes.

Q2 - Yes that’s right.

Q3 - Here’s a blog post that walks through creating a useful module to create “is this an xx device” type checks: http://www.coronalabs.com/blog/2012/12/11/device-detection-on-steroids/

  • Andrew
#3

thanks Andrew - do you happen to know of any other areas in a typical app where you would need to put such a programatic device check? I think this is the first I’ve come across so far (getting closer to trying to publish my app). ie most other things are catered for in the build.settings.

#4

For me, the only places where my code is conditional on iOS versus Android is (1) in setting up various identifiers for Flurry analytics and ad networks, and (2) in some of the text shown to the user (on iOS I might refer to their device as an iPhone or iPad, whereas on Android I would refer to it as a phone or tablet).

More often, I’m checking whether the code is running on the Simulator or on a real device.  For example, when I’m running on the Simulator, the code checks and knows not to use the in-app purchase APIs.  Instead of calling store.purchase() on the Simulator, my code simply passes some dummy data to my store listener.  That way I can check that the rest of the purchase flow using the Simulator.

  • Andrew
#5

Tks - simulator usage is a good idea. Do you like Flurry? Wondering if you’re looking at moving to Almplitude?

#6

I think Flurry is really good overall, especially considering that it’s completely free.  The only big things I don’t like about it are (1) it’s not real-time, (2) I can’t cut my event data any which way I like, using combinations of event parameters.  But I don’t really have a need for real-time data, it would be more just to satisfy my curiosity.

I looked at Amplitude briefly and wasn’t a fan.  On the one hand, it does have some cool selling points, like real-time data, retention by cohort, and real-time funnel analysis.  And the interface is snappy.  But it seems way too expensive for what it is.  You’d be surprised how quickly you can hit a few million events per month (depending on what event data you’re sending), and after that it costs $299 per month.  Also, based on the demo app that they show on their website, it seems to be missing a lot of essential analytics features, including:

  • User session statistics (average sessions per day/week/month), average session length
  • Ability to specify parameters for each event
  • Data on how many unique users performed each event, and how often per session
  • Statistics on the types of devices and OS versions your users are using
  • Benchmarks versus other apps in the same category

Flurry has all of these out-of-the-box.  Maybe the Amplitude demo on their site doesn’t show their full range of features, or maybe they’re planning to add them.  But based on the demo, I don’t think it’s nearly as powerful as Flurry.

  • Andrew
#7

Ok. I’ll have a look at flurry. Can you set like one funnel with flurry and pass it a parameter for what game level? Ie and then get for each level indication of how long to complete averages or whether people are giving up on a particular level. So in your code you wpuld just pass the level number. Seems in amplitude you would have to set up a funnel manually for each level (I think)

#8

There are a lot of ways to set up events and funnels in Flurry for different needs.

For me, I calculate within the app how long it takes someone to do a level, and I include that as one of the parameters on the event when the level is completed.  There may be other strategies to get that sort of info, but that’s how I do it.

  • Andrew
#9

Hi Andrew - do you have to setup different apps in the flurry interface for IOS vs Android?  If yes, wonder why this is?  Would be better if you could have a view of the one app no?

#10

I do set up the iOS and Android version as different apps, because when you create an app in Flurry, Flurry requires you to specify whether it’s an iOS app or an Android app.  I suppose you could create just one app in Flurry and call it, say, iOS, but use that Flurry ID for both your iOS and Android versions.  But I don’t know what would happen when the Android devices send analytics to that Flurry ID.  My guess is that it would just not work at all, or it would mostly work except for reporting which device users are using and tracking user acquisition.

  • Andrew
#11

Hi there,

Q1 - Yes, your goal should be to have one code base that you can build for both iOS and Android without having to make any changes.

Q2 - Yes that’s right.

Q3 - Here’s a blog post that walks through creating a useful module to create “is this an xx device” type checks: http://www.coronalabs.com/blog/2012/12/11/device-detection-on-steroids/

  • Andrew
#12

thanks Andrew - do you happen to know of any other areas in a typical app where you would need to put such a programatic device check? I think this is the first I’ve come across so far (getting closer to trying to publish my app). ie most other things are catered for in the build.settings.

#13

For me, the only places where my code is conditional on iOS versus Android is (1) in setting up various identifiers for Flurry analytics and ad networks, and (2) in some of the text shown to the user (on iOS I might refer to their device as an iPhone or iPad, whereas on Android I would refer to it as a phone or tablet).

More often, I’m checking whether the code is running on the Simulator or on a real device.  For example, when I’m running on the Simulator, the code checks and knows not to use the in-app purchase APIs.  Instead of calling store.purchase() on the Simulator, my code simply passes some dummy data to my store listener.  That way I can check that the rest of the purchase flow using the Simulator.

  • Andrew
#14

Tks - simulator usage is a good idea. Do you like Flurry? Wondering if you’re looking at moving to Almplitude?

#15

I think Flurry is really good overall, especially considering that it’s completely free.  The only big things I don’t like about it are (1) it’s not real-time, (2) I can’t cut my event data any which way I like, using combinations of event parameters.  But I don’t really have a need for real-time data, it would be more just to satisfy my curiosity.

I looked at Amplitude briefly and wasn’t a fan.  On the one hand, it does have some cool selling points, like real-time data, retention by cohort, and real-time funnel analysis.  And the interface is snappy.  But it seems way too expensive for what it is.  You’d be surprised how quickly you can hit a few million events per month (depending on what event data you’re sending), and after that it costs $299 per month.  Also, based on the demo app that they show on their website, it seems to be missing a lot of essential analytics features, including:

  • User session statistics (average sessions per day/week/month), average session length
  • Ability to specify parameters for each event
  • Data on how many unique users performed each event, and how often per session
  • Statistics on the types of devices and OS versions your users are using
  • Benchmarks versus other apps in the same category

Flurry has all of these out-of-the-box.  Maybe the Amplitude demo on their site doesn’t show their full range of features, or maybe they’re planning to add them.  But based on the demo, I don’t think it’s nearly as powerful as Flurry.

  • Andrew
#16

Ok. I’ll have a look at flurry. Can you set like one funnel with flurry and pass it a parameter for what game level? Ie and then get for each level indication of how long to complete averages or whether people are giving up on a particular level. So in your code you wpuld just pass the level number. Seems in amplitude you would have to set up a funnel manually for each level (I think)

#17

There are a lot of ways to set up events and funnels in Flurry for different needs.

For me, I calculate within the app how long it takes someone to do a level, and I include that as one of the parameters on the event when the level is completed.  There may be other strategies to get that sort of info, but that’s how I do it.

  • Andrew
#18

Hi Andrew - do you have to setup different apps in the flurry interface for IOS vs Android?  If yes, wonder why this is?  Would be better if you could have a view of the one app no?

#19

I do set up the iOS and Android version as different apps, because when you create an app in Flurry, Flurry requires you to specify whether it’s an iOS app or an Android app.  I suppose you could create just one app in Flurry and call it, say, iOS, but use that Flurry ID for both your iOS and Android versions.  But I don’t know what would happen when the Android devices send analytics to that Flurry ID.  My guess is that it would just not work at all, or it would mostly work except for reporting which device users are using and tracking user acquisition.

  • Andrew
#20

by the way Andrew - just extended my question here as I work out how to deploy to Google Play and Amazon securely - if you happen to have gone through this process would be great to get your comments on this new post:

http://forums.coronalabs.com/topic/43481-amazon-google-play-deployment-what-is-pseudo-code-for-license-checking/