Android targetSDK and HTTP stack
by Marko Strukelj
As we are leaning towards Level 10 as our targetSDK for Aerogear 1.0.0
we should consider current usage of HttpClient.
As Summers pointed out in #aerogear IRC, Google has deprecated the
platform HttpClient library, and stopped patching it.
Apache HTTP Client had been a lesser evil before, but has been
deprecated with Gingerbread (Level 9 API), and
java.net.HttpURLConnection has been bugfixed in later versions and
made the preferred choice [1].
The JavaDoc in one of google-http-java-client library classes sums it
up nicely [2].
We are currently using HttpClient in aerogear-android.
To be future proof we should therefore move to
java.net.HttpURLConnection. That API is one of those awkward early
java APIs that isn't very nice to use. The big sore spot from
backwards compatibility point of view is that HttpURLConnection had
some ugly bugs in previous versions.
Google for their part is developing google-http-java-client library
mentioned above - it's a wrapper library that checks current runtime
environment, and uses HttpClient underneath when API Level is less
than 9, otherwise it uses HttpURLConnection.
I haven't played enough with google-http-java-client to say we should
use it. It comes with quite some dependencies, but those seem like
optional, and it's possible that with the extent of functionality that
we require the whole lib after proguard treatment can be squeezed to a
really small size. But as I said, I need to play with it some more.
Any thoughts welcome.
[1] http://android-developers.blogspot.com/2011/09/androids-http-clients.html
[2] https://code.google.com/p/google-http-java-client/source/browse/google-ht...
- marko
10 years, 4 months
More on AeroGear 1.0.0.X timing and release plans
by Jay Balunas
Hi All,
I wanted to mention some things that I brought up at the team meeting about the release planning, versioning, etc....
__Version Conversion__
At what point do we want to synchronize our component versions for 1.0?
The original plan was to do this at the 1.0.0.Final release. My initial thought is that may be too late and we'll hit some snag that will cause us unforeseen issues.
Another option is converge at 1.0.0.CR1 release. Once we get to the CR1 release everything should be functionally complete and really only bugs, docs, examples to flush out. The CR releases are also quick 2-3 weeks max. Imo it makes sense to sync at this point.
__Versions Post 1.0.0.Final__
Once 1.0.0.Final goes live component versions should be able to move freely with point releases at least for now imo. Since this is a 1.0 a couple of point releases are sometimes needed to flush out unforeseen issues. We should not need to sync on them.
However for minor release (1.1) I do think it is important that we as a team decide and sync to that is required.
Then obviously for the 2.0 release we should all sync up again, but we can discuss that more at the F2F and as that comes closer.
__Final Prior to F2F__
Our face-2-face is the first week in February 2013. Although our plans mention have Final either late Jan. or early Feb. I think we should make a big effort to get the Final release out before our F2F so so we can focus on the future!
__PicketLink Release__
Picketlink is planning to release a Final around December, so the timing could be good for us to update any security requirements and get that into our Final release.
So what do you guys think? Any thoughts, concerns, questions, comments welcome!!
Thanks,
Jay
10 years, 4 months
Android Auth branch and API
by Summers Pittman
My initial work is here:https://github.com/aerogear/aerogear-android/tree/auth
Changes to existing classes/API:
HttpProvider now returns a class called HeaderAndBodyMap . This is a Map of the headers along with a byte array which was the body of the response.
HttpProvider will throw a HttpException if it does not receive a 200 status
HttpException wraps some information about the HTTP result.
Description of current Auth Classes and Methods:
<blockquote>
Interfaces :
<blockquote>
Authenticator is a factory/lookup class a la Pipeline.
</blockquote>
<blockquote>
</blockquote>
<blockquote>
AuthenticationModule is a module that manages a authenticated users credentials. Provides enroll , login , logout , authToken , and isAuthenticated .
</blockquote>
<blockquote>
</blockquote>
<blockquote>
Builder is an interface that can instantiate an instance of AuthenticationModule .
</blockquote>
Classes:
<blockquote>
DefaultAuthenticator implements Authenticator
</blockquote>
<blockquote>
</blockquote>
<blockquote>
RestAuthenticationModule implements AuthenticationModule only login is implemented.
</blockquote>
</blockquote>
<blockquote>
</blockquote>
Todo:
<blockquote>
Implement the rest of the methods in RestAuthenticationModule
</blockquote>
<blockquote>
Update Pipe implementations to use the AuthenticationModules
</blockquote>
<blockquote>
</blockquote>
<blockquote>
</blockquote>
10 years, 4 months
Big picture questions around the PipeManager and the DatastoreManager
by Sebastien Blanc
Hi all !
I was looking at the all different documentation pages and FAQ, and some
questions and ideas araise :
1) A PipeManager can contains 'n' pipes, is there any plan to be able to
chain pipes together (i.e : "localPipe -> restPipe") ? Even nicer, would it
be possible to make conditional the pipe "route" (i.e ; "no connection then
use the localPipe" etc ...)
2) The dataStore concept is clear but are there any plans to create some
sort of association (one-to-one, one-to-many, etc ...) between a pipe and a
datastore instance ?
3) One idea should be that a pipe produce events ("entering pipe","exiting
pipe", with some useful callback data) and then any other component should
be able to register to the pipe's events, same could be implemented for the
other components (datastore events , security events) ...
The main idea is how we will consolidate all this different
components together (pipe and datamanager mainly) onces we will have to
deal with data sync for example.
I'm just throwing some ideas after a brainstorming with myself ;-) but
please share your comments on this !
Best Regards,
Seb
10 years, 4 months
Android target and min SDK numbers
by supittma＠redhat.com
Following a spirited discussion on the IRC channel we have come up with
the following arguments for and against several minimum versions of
Android which we will support for 1.0
android-7 Éclair
For:
The TODO app currently compiles and runs on it
Against:
Older than cyber dirt.
Relies on some deprecated HTTP Cient APIs
More testing for not much more gain in market
android -8 Froyo
For:
We agreed on it before.
Gains us 15% of Android Play users
Against:
Still uses deprecated http libraries.
Lose out on some of the nicer things in Gingerbread
Can lower our minimum version in 1.0.1 if it passes QA
Old as cyber dirt
android-10 Gingerbread
For:
Majority of Android users still use this
Lots of good API's
"Default" version for many Android developers
Minimum version that the supported http libraries support
Against:
We lose the users from Froyo
We agreed on Froyo before
The library doesn't strictly need it.
My vote is for 10 with an eye to lower it to 8 shortly after 1.0 is
released. This limits the number of platforms we have to test on to get
this out the door and doesn't affect our developers that much.
10 years, 5 months
Restructuring AeroGear Security
by Bruno Oliveira
Ahoy-hoy.
Today I was programming into my cave also known as darkness of justice. After some discussion with qmx about ag-security, I was just wondering about split the project to be less tightly coupled to PicketBox.
Why? Because I'd like to get rid of all the PicketBox infrastructure source code.
So what do you guys think about? I'd like to create 2 repositories:
- aerogear-security: DSLs exposed to the final user and has a spi implementation for the integration with PicketBox as a provider
- aerogear-security-picketbox: Provider implementation with all the infra-structure code.
Concerns?
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
10 years, 5 months
AEROGEAR-559 android: can only build with -DskipTests
by Bruno Oliveira
Hi everybody! I was reviewing Marko's PR (https://github.com/aerogear/aerogear-android/pull/14), but as you know I'm not so good with Android, so here comes a few dumb questions.
Following the documentation http://developer.android.com/guide/topics/manifest/uses-sdk-element.html these attributes specifies what's the mininum API level required and the targetSdkVersion attribute specifies the API level that application targets, right? Are we targeting only the API level 7?
android:minSdkVersion="7"
android:targetSdkVersion="7"
Why targetSdkVersion can't be 16 for example? Just because RoboEletric uses the API level 10 as default?
Maybe is just a matter of configure RoboEletric plugin instead of change the targetSdkVersion?
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
10 years, 5 months
Android library: Are nulls icky
by supittma＠redhat.com
So I try to avoid nulls wherever possible. In the case of the
Authenticator (and Pipeline) API's we have methods get(String name).
The obvious thing to do would be to return a null object if the name
isn't a known name.
Would it be better/preferable to return some kind of default
AuthenticationModule (or Pipe) which does nothing instead?
Alternatively we could supply a peek(name) method which tests for the
name and throw an exception if you call get with a bad name.
Just some idle thoughts.
Summers
10 years, 5 months
