Develop Reference

GET JSON response from AEM

One of the requirements for our native mobile apps is to retrieve a config JSON that can easily be changed during production. For example, in our apps, we will hit up a URL that returns a JSON response containing features that the business wants enable, disabled or list of base URLs:
GET https://ourwebsite.com/mobile_config/
RESPONSE
{
"enableFeatureA": true,
"enableFeatureB": false,
"baseUrls": [
"foo",
"bar"
]
}
To meet the requirement of it being configurable during runtime, we're planning to use a content management system, which has a publishing feature. We've recently been looking into AEM as our new publishing tool. My idea is to save a JSON file into the AEM content manager, and when a GET request is made to the URL, the backend will read the JSON file and return it as an 'application/json' content type. However, I can't find any obvious way to achieve the result of returning the contents of the JSON file when making a request using AEM.
Being fairly new to AEM, my guess is just create a jsp file to read the contents. But how do I return it? How do I manage the 'routes'? Do I need to set up a template? Is this the best approach?
Any guide is appreciated.

AEM reserves the use of .json as an extension; it uses it for RESTful views of content in a JSON format. You might have luck using a different file extension, such as filename.foo - but it'll probably give you the wrong mimetype unless you configure Dispatcher to fix this. This probably isn't the most considerate approach.
In short, if you upload a .json file into the DAM, you won't get what you expect. You'll end up with a path that looks something like /content/xyz/abc.json - but it'll render with the AEM JSON code, and give you the properties from the datastore instead of your file.
It is possible to turn off AEM JSON output, but it tends to break things as noted in the Security Checklist. Besides it tends to be blocked in Dispatcher configuration anyway most of the time (depending on local policy).
One approach, assuming that Dispatcher does allow JSON requests (or that you are able to permit this safely) is to create a JSON.jsp a page or component, and have the JSON data as a property. This also can have side effects in the authoring interface, as the JSON can interfere with the edit dialogues.
I think the best option might be to use static replication to publish the file onto a static webserver. This is done as a separate replication queue. There's a related question here that may help.

I have recently done something pretty much identical to what you are asking. I created a featureToggling AEM component to allow runtime authoring of specific features of standalone angular applications. The angular application looks to the JSON content stored for my featureToggle component as the app initialises and enables/disabled features based on the values stored.
The component itself is a multifield that allows me to add multiple feature types with a toggle switch to turn them on or off. The JSON for ALL AEM pages is actually exposed by appending .infinity.json to the end of the url. My angular app simply reads from and interprets the JSON on initialise then shows/hides features of the app.
EG: http://[mysite]/[featureTogglePagename].infinity.json

Share lots of data between android applications using internal storage?

Background: we are porting an enterprise system to have android clients. The architecture for windows and html is based around a core library that does the hard business logic but no user interaction at all, and we use programs or single page web apps to provide the user interface and simply call the core API library to actually do stuff.
The "core" is implemented as a shared library on windows and built into each app. If we mirror this and use a java library, we need to share files using external storage, which is a not permitted as data needs to be reasonably secure. (Nb data is binary data, not Sql database, in case that is relevant)
So we thought about using a bound service, and using intents, content provider etc, but it seems (from googling) we must then distribute the background service separately the user interface app, but this seems terrible experience for new users. However, a bound service seems ideal from all other angles.
We also cannot guarantee which apps a user might download, we will have at least 10 individual apps all doing logically different things, but referencing similar data.
In brief:
lots of individual apps all wanting access to same data
no control over which apps are downloaded
using external data is not permitted as data should be semi secure
using sqllite might not work as data is long binary chunks ( eg 3Mb plus ). (Ref: How to share data across a group of applications in Android )
some data files are big and do not want every app to download a private copy
some data changes dynamically, say every 15min
core business logic is big and complex, cannot be distributed in source form, lib/jar ok though.
the windows solutions all use network IO to an application server, but we want to avoid as much network traffic as possible by storing data locally.
How can we bundle a bound service in each and every user interface app we distribute? Or is there a different way to approach this whole design?

I think that there is a few number of options that you can explore:
1) I never have done this before though this seems possible as Android is package based.
First you need to use the same main package across all your apps though each app must be in a separated sub package, e.g. : main -> au.com.myapp.main and the app actually have it's first screen on app1 -> au.com.myapp.main.app1 .
Create on your main app a method(s) that will look for those extra packages (within your project), as it find something you create a trigger that will display a item on the menu. Each app should have the same main packages and main activity, as it will be responsible for enable the user have access to the others and all of them can share the same preferences, files folders and Database.
When installing the same packages should be overrides though those different ones should keep intact. You should have all the 'main' classes for each app, not the real main one declared on your manifest (that will be quite big depending on the amount of activities in all your apps) with those packages.
2) You can using Spongy Castle, create a shared zone (folder) where you create the DB and write your settings or files, encrypting everything with a key (strong one or using RSA) that might be made by the user or provided once for your company at the very first run. You must decide how to handle this.
3) You also can use the share id in all your apps and each app before run perform look up for all packages (it's possible to do) to know and if and what packages exist to check if there is a DB with data in that package.
4) Not really nice though create a background service that keep updated all tables in all apps (sharing id or using content provider), you can user AlarmManager to trigger it in intervals rather keep it on at all times and you have all apps.
My last project had a similar requirement though as the user had to login to do anything, I opted for the option 3 and each data pertinent exclusively to each app went the app DB.
I hope this helps.

Extending an existing Web application with Android app

I have a new project involving the build of an Android app for a website of a hiking club. The website has a login functionality after which the user can browse through available hikes, subscribe to a hike, view the other subscribers, contact the organizer etc.
The original site is based on a MySQL database with a front end of .asp pages. Most data is passed through the pages as GET parameters on the query string.
New to Android development, some things really puzzle me, even after reading several tutorials. I am thinking towards an architecture baes on REST webservices but there a several obstacles to overcome and chooses to be made.
Apart from using REST, some other options are available:
Call the original .asp pages from the app instead of building a dedicated Web service. This leaves me with much less code to write, the original business logic (queries e.a.) as well as the login system can be used (with the "remember me" functionality based on cookies). Downside is that the (X)HTML code in the response needs to be parsed to show in the app GUI, where the majority of the response code is useless ballast code. Also, it does not feel very good from an archtitectorial point of view.
Using a SOAP based webservice. I am totally unfamiliar with SOAP and it appears to be much too heavyweight for a mobile device.
Using REST services. I am leaning towards this option, and have made
some already working services using the SLIM framework. But there
are some problems. First, REST is stateless by definition and does
not seem to support sessions. But the "Remember me" option is
required for the app after login in for the first time, the user
needs not to login again unless he explicitly logs out.
But how can we achieve that?
First option is to designing some completely client-site login/logout system which saves the credentials locally until the user logs out. And sending the credentials with each request to the Web service as POST parameters, or somehow in the HTTP Authorization request header, though I am not familiar with that.
Second option is to deviate a bit from RESt principles and use a session mechanism anyway. After sending the credentials to the web service, a cookie is created and send to the client app. The dartabase cannot be extended so there is no option to save a token in the user table. Maybe the usernae/password can be encrypted and send as a cookie to the app, and decrypted at each subsequent request?
I am a bit lost in this, and look forward to serious suggestions!

I believe that from a long term perspective, it is important that you lean towards REST Interfaces. While JSoup and/or WebView approaches will definitely work, it is important to have the flexibility to redefine/design the mobile application in ways that are completely agnostic of the Server side. REST will help you there and you do not need to play catch up with the Server side, everytime they change the HTML pages, etc.
Going REST will also help in future with writing additional mobile applications and even on different platforms like iOS, if your roadmap contains that.

You can use jsoup to parse the html pages from your Android app and reorganize the information of the web page, this option will gives you ability to quickly develop an App, later you may think on add REST interfaces to your web site and populate data in json.
You can also use WebView to laod your web pages if you don't want to parse html pages.

I suggest you using REST architecture as you said. You can use a rest client library for Android as RESTDroid, take a look to the guide because there is a implementation example with special header needed for the particular web service used (Parse.com in this case).

How do REST URIs work internally?

I'm trying to create a REST API to interact with a MySQL database. I want to use this API to access the database from an Android or iOS device without (obviously) exposing the database directly through the application. But I'm having problems wrapping my head around a key aspect about REST and the implementation of an API designed on its principles.
I understand the concepts of REST from the theory stand point. What I've been struggling for days trying to grasp is how a REST URI maps to something located on a database server.
If I make a GET request to a server for a resource with a given URI, say http://www.example.com/resource, internally, where does this go to on the server? The way I understand it, is that it goes to the root directory, then to the "resource" directory. From there it returns all the files within that "resource" directory. I'm simply confused because the resource is located on the database server and not the server where the API is being called from. Does the resource path/hierarchy represent actual directories on the server or is it an abstraction of the resource? If the latter, then what do I do with that abstracted resource name to make it map to a table or row in a database? It's been frustrating not being able to find concrete implementation examples of this where I can easily understand how this URI path works internally.

You can use a framework to do a lot of the work for you, but what happens under the hood is no magic. In some way, the URIs map to some database tables. They don't refer to a certain directory structure, but try to explain a hierarchical relationship between the resources.
For example, let's say that we're modelling a university. The elements in the database are stored in one of two tables, either Faculties or Courses. The Faculties table consists of rows describing the Faculty of Law, Faculty of Medicine and so on. It has a unique faculty_id column and then columns to describe whatever we need. The Courses table has a unique course_id column and a foreign key faculty_id column, to tell which faculty the course belongs to.
A RESTful way of designing this API might be
/faculties to get a list of all faculties, retrieved with SELECT * FROM Faculties
/faculties/2 to get the information about a certain faculty, retrieved with SELECT * FROM Faculties WHERE faculty_id=2
/faculties/2/courses to get all the courses belonging to a certain faculty, retrieved with SELECT * FROM Courses WHERE faculty_id=2
/faculties/2/courses/15 to retrieve a certain course, if it indeed belongs to faculty 2, retrieved with SELECT * FROM Courses WHERE faculty_id=2 AND course_id=15
The exact implementation of this depends on the programming language (and possibly framework) that you choose, but at some point you need to make choices about how you should be able to query the database. This is not obvious. You need to plan it carefully for it to make sense!
The result from the database will of course have to be encoded in some way, typically XML or JSON (but other representations are just as fine, although maybe not as common).
Apart from this, you should also make sure to implement the four verbs correctly so that they match the SQL commands (GET=SELECT, POST=INSERT, PUT=UPDATE, DELETE=DELETE), handle encoding negotiation correctly, return proper HTTP response codes and all the other things that are expected of a RESTful API.
As a final piece of advice: If you do this neatly, it'll become so much easier for you to design your mobile apps. I really can't stress this enough. For example, if you on a POST request return the full entry as it now looks in the database, you can immediately store it on the phone with the correct ID, and you can use the same code for rendering the content as you would if it had been downloaded using a GET request. Also, you won't trick the user by updating prematurely, before you know whether that request was successful (mobile phones lose connection a lot).
EDIT: To answer your question in the comments: Creating an API can be seen as a form of art, and should probably not involve any coding in the design stage. The API should be meaningful and not rely on a particular implementation (i.e. a different database choice shouldn't affect your API). Your next task will be to create ties between the human-readable structure of the API and your database (regardless of whether it's relational or something else). So yes, you will need to do some translation, but I don't see how the query string would help you. The typical structure is api.my.website/collection/element/collection/element. Queries can be used for filtering. You could for example write example.com/resource?since=2012-06-01 to retrieve a subset of the elements from your 'resource' collection, but the meaning of this particular query is to retrieve something you couldn't express with an unique ID.
The way I understand it, you think that incoming requests must always go to separate files based on the way PHP and HTTP servers work. This is not the case. You can configure your web server to route every request to a single PHP file and then parse $_SERVER['REQUEST_URI']. Depending on your choice of HTTP server your mileage might vary, but this is essentially what you want to do.
By googling I found a list of frameworks for PHP but I don't know any of them. There are others, though, and I also recently heard someone mention Apify, although I can't tell you much about that either. PHP is probably one more the more common choices for implementing an API. cURL, however, is a library/tool that's only designed to connect to other websites, as far as I know. You can certainly use the command line version of it to debug your API, but I don't think you'll have much use for it on the server side.

I think you should start with what framework you want to built the REST application from. Rails, RestEasy for java, Codeigniter, all have the basis for good REST routing capabilities.
This includes abstracting URL's from the underlining resource either from database or even business processes. They accomplish this using URL mapping, or creating a Facade for abstractions.
Generally REST does not really differ from tradational GET/PUT/POST with query parameters. Infact Apache URL rewrites usually are used to support REST style routing. I recommend you should pick up one of the frameworks and study how they implement this functions. Rails i thing has significant strength among other frameworks.

Android: In-App In-Place Updating

I have an Android app, where a part of the app is a list of data which is currently contained in a string-array (in an xml resource). I currently release updates every so often to the actual app, which do nothing more than update this list of data. (yes, in hindsight this method was a bad idea to start with).
My goal now is to change this so that I will be able to only update that one part of the app that needs to be changed. I have a webserver, and am now serving a JSON version of the data off a URL. So all the app has to do is hit that URL, check if it changed (perhaps using a version number), and then update.
My problem lies in the actual implementation:
Where/how should I store this data? As a raw file? SharedPrefs? Database? [i.e. what are the pros and cons of each]
How can I preform a seamless upgrade where even if something devastating happens during the update [such as a user pulling a battery...], it still won't break the app?
Should the updating code live in a service?

I would separate your data crud into a small background service. Use the provided SQLLite. To verify data consistency you could use md5 checks, database rollback features and most importantly design a small set of tests. One only sending a partial file, i.e. "the broken transmission test", garbage file, etc. Keep it a separate and testable component of your app.