Looking at the instructions for the project in gihub, there are “sparse” – to say the least. We guess that we needed the Android Development Platform – which we duly installed on MacOS. (We customized that further – for the Amazon kindle platform upon which we intend to test the app.).
While I could almost import the repository from the github URI, the import tool could not find any project (and thus failed to complete importing.) So, we used the “general project” option, instead.
Running this project produces error messages about “default launchers”.
So, we created a dummy android-application project, called foo, and compiled and ran it – hoping to fully configure all the tools settings – including configuring a virtual machine to run the app under:
adding skin and CPU, to the defaults of “create AVD”
starting the VM
for app “foo”
Turns out that this doesn’t help us build and launch our “general app” – but we learned a lot! So try an import into new project from existing files:
Running this project, we do get to select a run time now:
gets us along way to at least seeing a running vm (of the wrong api level,so far)
So, not knowing much about this stuff, we just create the latest API level device (19, today):
which gets us as far as
note the comments about loading apks, and launching microsoft apps.
after dragging the lock item to the right to open up the main viewport of the phone we see
which is all very nice, as a todoapp, but where is the office365 logon?
we see that the code has some pre-configured office 365 configuration information. So let’s change that for our own!
using safari browser to configure an AAD client app, in windows azure portal
align code with newly generated client id for the client-app
align code with the server API we deployed from the microsoft wfp->webAPI sample project (also used by the IOS app to webapi sample).
Now we hook up the client (logical proxy in AAD land) with the server (logical proxy in AAD land), using the AAD “enforcement and connectivity security model”:
This means that token re-issuing – when an id-token is to be swapped for an access token (or refresh token) is constrained – to enforce the policy noted above – at issuing time. This or course dumbs down apps (just the way CIA/NSA want them), putting power and communication control in the hands of a few cloud vendors (just the way…)
Ok Running the project makes no difference to the use of the API – which clearly does not depend on the constants which just re-coded.
ok. its clear that we have to now go do whatever it takes to “install” the android ADAL project itself – so it presumably augments this app project – and gives us some code fragments perhaps.