[iOS] SQLite store implementation
by Corinne Krych
Hello Guys,
Working on initial shot of AGIOS-25 [1] (Implementing SQLite Store), I’m wondering how to deal with KeyValue (ie. Schema-less) vs Schema Database (SQLite and same discussion for Core Data [2])?
- how to handle dynamic changes of schema?
My first thought is to it as limitation with SQLite storage.
Or could we have a more flexible approach (with of course a cost), if there is extra columns, update the table schema, if less columns put null values.
- embedded relation?
Just store them as ‘blob’ like values or create another table?
SQLite imlemetation work in progress can be found [3]
And if you think of other topics KV/Schemaless impedance, please bring them on.
++
Corinne
[1] https://issues.jboss.org/browse/AGIOS-25
[2] https://issues.jboss.org/browse/AGIOS-14
[3] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-25
13 years
aerogear-js-integration repository structure
by Apostolos Emmanouilidis
I was thinking of removing the bash scripts (server folder) and setup a
Grunt plugin which will contain all the tasks required to setup the
servers and execute our tests. This is already done for the Aerogear JS
REST adapter CORS/JSONP tests. We have created a Grunt-QUnit [1] plugin
(the whole plugin is written in JavaScript) which is able to download
JBoss AS, start a server with customized JVM parameters, setup custom
HTTP/HTTPS ports, setup a keystore, build a maven project, (re)deploy an
archive on JBoss AS and finally execute the QUnit tests and kill the
process after the tests are executed. The CORS/JSONP tests are already
running on Travis CI [2] using the Grunt-QUnit [1] plugin.
We could add more tasks inside this plugin, remove the bash scripts and
make the aerogear-js-integration a whole JavaScript repository.
wdyt?
[1]: https://github.com/tolis-e/arquillian-grunt-qunit
[2]: https://travis-ci.org/tolis-e/arquillian-grunt-qunit
13 years
TODO app abandoning
by Christos Vasilakis
Hi team,
opening this thread to continue the discussion we had on our IRC meeting of whether we should abandon(or not) further development of our TODO app demo. There was a suggestion on the meeting to close any pending tickets regarding TODO and mark the app as 'Not maintained'.
My personal preference is to keep it till our 'showcase' eventually replaces it. This is related to our discussion on 'showcase' app ML threads here and here
Also, at least in iOS, for the feature set that the API utilises (Pipes, Store), the app is still up-to-date but I am not sure if that holds true for our other platforms too.
What do you think?
Thanks,
Christos
13 years
Authentication issues
by Summers Pittman
We've been updating/regression checking some of our older demos on the
Android side of things and are having trouble authenticating against the
controller demo.
Right now Android posts the following:
{"password":"123","loginName":"john"
to
http://controller-aerogear.rhcloud.com/aerogear-controller-demo/login
and receives
HTTP/1.1 400 Bad Request
{"error":"AG_CONTROLLER000010: Parameter: 'password' was missing from
Request"}
Any thoughts?
13 years
Arquillian Droidium for Aerogear Android OTP demo
by Stefan Miklosovic
Hi,
I am developing Arquillian container for Android called Droidium (1). To make the story short (since it is realy long),
it brings Selenium and Arquillian Graphene + Drone power into your functional mobile tests. It can:
1) Test your Android native application functionally meaning you
- have your APK you want to test
- start Android emulator dynamically upon test execution or you connect to already running one (physical device as well)
- APK is deployed to your phone, you write Selenium like tests where you are clicking around the app
- All tests pass so you are happy.
2) Test hybrid Android applications meaing your application consist of native + web view, you can switch between them in one test case.
3) Test web applications from your mobile device (emulator / physical) meaing
- you have application like a WAR
- you have application like an APK
- Droidium starts JBoss AS for you and WAR is deployed there
- you have emulator (started / stopped) or physical device
- WebDriver from Selenium is installed on the device so when you are doing tests, Android browser is open for you and you are
executing tests on mobile phone against deployed web application
4) You are able to deploy more than one deployment (meaning APK) when you are doing tests, so you can install not only APK you
test but all serivces ore resource libraries.
All test cases coded so far are located here with brief explanation what it is doing for you
I am writing this to you since I have been assigned to https://issues.jboss.org/browse/MP-112 where I need to verify that
I can use OTP for Android. Since it is little bit unclear for me, I propose my own "test case" for this.
1) I take web application "as-is" here (2) and I deploy it to JBoss AS instance
2) I take this OTP Android demo here (3) and I install it to mobile phone.
3) I fill in forms in Android emulator with name / pass and when I get the number, i take that and I enter that into web application
4) I verify that I am logged in the web application
5) OTP for Android works.
Questions:
1) Is there some other use case scenario how it should be tested?
2) I heard that OTP demo is little bit obsolete so maybe some additional plumbing here and there would be necessary. Otherwise,
what would you like to see regarding OTP and Android tested?
3) Do you see a room for incorporating Droidium into Aerogear more deeply? I could deep e.g. into AeroGear controller and do some
testing there or security would be very nice area as well. This tool is pretty handy in QA and AeroGear would benefit from that greatly.
Regards
(1) https://github.com/arquillian/arquillian-droidium/tree/master/tests
(2) http://controller-aerogear.rhcloud.com/aerogear-controller-demo/
(3) https://github.com/aerogear/aerogear-otp-android-demo
Stefan Miklosovic
Red Hat Brno - JBoss Mobile Platform
e-mail: smikloso(a)redhat.com
irc: smikloso
13 years
