[iOS] CoreData (was: Re: [iOS] supported version)
by Matthias Wessendorf
current thinking is, to keep the "core" AeroGear (for 1.0.0 timeframe)
on iOS 4.x.
Things like "Mantle" (for model layer API), are _NOT_ part of the
framework. (this requires iOS5).
So if uses want to build the model layer around Mantle, they can use
AeroGear - but it's their decision to go with iOS5 (which makes
sense...)
For our CoreData support, I *think* we will get a "plugin" (based on
AFIncrementalStore/NSIncrementalStore), which will be based on iOS5...
So, if users want that plugin, it's iOS5.... current status of my
CoreData thoughts... will probably post some more details on Monday..
Greetings,
Matthias
On Sat, Nov 3, 2012 at 10:08 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Let's stay on iOS 4.x at least for the 1.0.0 timeframe ..
>
> -M
>
> On Fri, Nov 2, 2012 at 2:21 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>> btw
>>
>> http://www.quora.com/iOS/Where-can-I-find-an-current-statistics-for-iOS-v...
>>
>> -M
>>
>> On Mon, Oct 29, 2012 at 1:06 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>> nope.
>>>
>>> As I said on the IRC, on Friday - I am fine to consume AFNetworking
>>> 1.0.RC1 and stay on iOS 4.x
>>>
>>> Perhaps after 1.0.0.Final is out we can change that... if needed
>>>
>>> -M
>>>
>>> On Mon, Oct 29, 2012 at 12:29 PM, Kris Borchers <kris(a)redhat.com> wrote:
>>>> Hmmm, dropping iOS 4.x seems like a lot of users but it is also pretty old. Do you know where we can get usages stats?
>>>>
>>>> On Oct 29, 2012, at 2:31 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> the M1 release supports 4.x (I think 4.6)....
>>>>> However, our (current) main dependency (AFNetworking) is aiming to
>>>>> support iOS5+, starting with version 1.0!
>>>>>
>>>>> Right now, the development branch is currently against 5.0 as well...
>>>>>
>>>>> Would you guys support 4.x - or is iOS 5.0 good enough? Huge downside
>>>>> would be that we are stuck on AFNetworking 1.0-RC1 for a while....
>>>>>
>>>>> -M
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 1 month
[iOS] update - open issues for M7
by Matthias Wessendorf
Hola,
looking at the open 'iOS items' for our umbrella AeroGear 1.0.0.M7,
below are the open tickets:
BUGS:
* AEROGEAR-638 - iOS: pipe: delete: add check for NSNull value
==> (very) simple fix + test
* AEROGEAR-649 - iOS: read single entity from the rest-endpoint
==> (very) simple fix + test
TASKS:
* AEROGEAR-614 - iOS: improve unit tests
==> Christos is working on that
* AEROGEAR-626 - iOS: tests: add mock testing on the library
==> Christos is working on that
EPIC (and sub-tasks)
* AEROGEAR-634 - iOS: model API: investigate on Model API
** AEROGEAR-652 - iOS: CoreData investigations
** AEROGEAR-653 - iOS: TODO app: show CoreData/AFIncrementalStore usage
==> I am currently looking at CoreData and AFIncrementalStore;
IMO, overall this looks very good, especially with the fact that we
have almost 3.5 more weeks to go...
As always, feedback is welcome...
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 1 month
Xcode getting started
by Deepali Khushraj
Hi,
All steps in the guide worked well, except for one manual change, without which I was getting a runtime error:
In didFinishLaunchingWithOptions of AGAppDelegate.m, I had to manually change the line:
from: self.viewController = [[AGViewController alloc] initWithNibName:@"AGViewController" bundle:nil];
to: self.viewController = [[AGViewController alloc] initWithStyle:UITableViewStylePlain];
It'd be great if this change is reflected in the guide: http://aerogear.org/docs/guides/GetStartedwithAeroGearandXcode/
Thanks!
Deepali.
12 years, 1 month
[android] Response headers case sensitivity
by Marko Strukelj
*At the moment our Android library is sensitive to response header cases.
What that means is that if a web server returns auth-token: xxxx-xxxx
instead of Auth-Token: xxxx-xxxx our RestAuthenticationModule fails to find
the token.
I found this interesting issue on the topic:
https://github.com/joyent/node/issues/1954
HTTP Spec indeed says that headers are case-insensitive. But the whole
world seems to go towards a more practical approach of case sensitivity, as
it’s simpler to lookup headers that way.
Incidentally, I discovered this while using an integration testing module
I’ve been working on:
https://github.com/mstruk/exploratorium-android-rest(it's a work in
progress).
The rationale is that really testing the code means going through as much
of a real runtime as possible - like using Arquillian ...
At first I thought it was HttpClient, and HttpURLConnection APIs
lowercasing the headers. Turned out it was the embedded HTTP server.
The question in this case is do we call this an issue or is this something
we don’t care about.*
*
*
*- marko
*
12 years, 1 month
Aerogear Android Packages
by Daniel Passos
Hi Guys,
I'm having some doubts about where to put some classes.
Working to make id configurable I created two classes Scan (to search for a
annotation) and Property (to encapsulate reflection property calls) where I
should put these classes? I created some exceptions. We should have a
package for exceptions?
Also I was in doubt whether the classes HeaderAndBody and HttpException
should not be moved to the package impl
wdyt?
Att,
Daniel Passos
12 years, 1 month
[iOS] how to write a model layer for AeroGear
by Matthias Wessendorf
Hello,
right now the save/read of our pipes are pretty generic and they
"just" work with maps (NSDictionary) and array (NSArray) objects, due
to the nature of ObjC.. Over last days I did some "research" on how to
support a better "model layer" with AeroGear see [1].
As mentioned in the previous blog post, Github's Mantle looks like a
nice option to use, when writing "model layer" APIs... Right now the
AeroGear does NOT directly include the Mantle framework for offering a
"better" model layer - the API is still using NSDictionary and
NSArray. This is simply because sometimes folks want to maintain their
own "getAsDictionary" and "initWithDictionary". Also the current API
works fine with the Mantle framework, see [2].
So there is choice - and yes... room for improvements...
## What's next ? ##
I want to take a (deeper) look at CoreData and how to (remote) persist
those "managed object". In particular I want to take a look at
AFIncrementalStore, which is a AFNetworking based library (hint) to
"map" CoreData to HTTP.
As always, feedback is welcome!
Greetings,
Matthias
[1] http://matthiaswessendorf.wordpress.com/2012/11/19/objc-json/
[2] http://matthiaswessendorf.wordpress.com/2012/11/20/using-mantle-with-aero...
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 1 month
