Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>IMO your best approach to creating multiple app releases from a single source <em>is</em> to use a library project.</p> <p>I've attempted this recently and it seems to work very well. Although I haven't tried releasing code based on this to Google Play, I've created separate apps which can both run at the same time on a test device, with their own icons.</p> <p>Since separate apps on Android must each have a different package name, the easiest way to configure separate behavior is to test that package name in your library to see if it is presently running within the free or the paid version. That test can be made within a custom Application-derived object defined in the library project; the package name can be obtained there by calling getPackageName().</p> <p>Your free and paid apps, at a minimum, may need only an AndroidManifest.xml file and a few resources (e.g., an application icon that distinguishes free from paid).</p> <p>In the manifest for each of the two apps you will want the application element to have its android.name attribute set to the full path to your custom Application-derived class (as defined in the library). And of course you will want to have the package= attribute of the manifest element itself set to a distinct package that ends in something like .free or .paid, for the respective apps. The activity objects in the manifest can then have an android:name attribute that is set to the proper Activity-derived class in the library (using a full path).</p> <p>The code that enables your paid features will then simply call the methods that test the package in your custom Application object, parse the package name, and decide on that basis whether a paid or free version is running, and then enable or disable the paid features accordingly.</p> <p>There is a very helpful example (although somewhat old, still relevant) with full code, here:</p> <p><a href="https://github.com/donnfelker/FullAndLiteVersionSharedLibrary/blob/master/FooLibrary/src/com/example/foolibrary/FooLibraryApplication.java" rel="nofollow">https://github.com/donnfelker/FullAndLiteVersionSharedLibrary/blob/master/FooLibrary/src/com/example/foolibrary/FooLibraryApplication.java</a></p>
    singulars
    1. This table or related slice is empty.
    1. POAndroid free and paid with different functionality
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USCarl
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you for that response. In the end I have gone with a library project. Check out another question I asked and the answer I received. It might help you: http://stackoverflow.com/questions/11176113/android-free-paid-architecture-using-library
      singulars
      1. PO
      1. USJames Cross
    2. COIn that other thread I was properly corrected for suggesting that variant behavior in the library could be conditioned on testing the package name of the containing app. It could violate modularity to configure library behavior based upon what module is *using* the library. So all app-*specific* information should reside in the app, when applying the approach described above. If you are just disabling features then it might be OK to do so based upon the app's package, but if you have, say, a dialog variant for free vs. paid then those dialogs should reside in the apps, not the library.
      singulars
      1. PO
      1. USCarl
    3. CORegarding how this need (for a library project) evolves, I suspect that a dev typically creates a full-featured app and *then* decides to create a free version with disablements, and this results in most of the full app ending up in the library project, with a test of the app package in the library to control the disablements. This is arguably not ideal as you are loading unused stuff into the free app. OTOH, it's necessary if you want to enable features later on (e.g., with in-app payments). and it may also compromise coherence to divide the full app between the library and the app proper.
      singulars
      1. PO
      1. USCarl
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload