AEROGEAR-540 - Aerogear.js filtering
by Lucas Holmquist
https://issues.jboss.org/browse/AEROGEAR-540
i created this on monday, but now i'm thinking otherwise.
The Data Manager Memory adapters filter method will only search on level of an object( at least i think). i was thinking we might need it to do a recursive search to find items not on the first level.
ex:
var object = {
name: thing,
value: {
thing2: thing3
}
}
alreadyCreatedDataManager.filter( { name:'thing' } ) => returns object
//currently this happens
alreadyCreatedDataManager.filter( { thing2:'thing3' } ) => returns empty [ ]
//with recursive
alreadyCreatedDataManager.filter( { thing2:'thing3' } ) => returns object
Now i'm not sure if thats the way to go.
Thoughts against:
bloat the code, developers could do this themselves when they get the data back, keeping our library leaner
Thoughts for:
Be nice to the developer
like to hear other thoughts
13 years
1.0.0.Final release dates and AEROGEAR-521
by Jay Balunas
Hi All,
Wanted to touch base on some items that Matthias brought up about release dates and that our roadmap is out of date.
Typically our CR & Final releases are shorter release cycles because at that point its functionality complete, and working on demos, docs, and bugs. Also moving to just times in the month instead of dates is a better idea imo.
So I would say:
1.0.0.M6 => late October 2012
1.0.0.M7 => late December 2012 (before the holidays!)
1.0.0.CR1 => mid January 2013 (roughly 2-3 weeks after M7)
- All libraries and primary demo's should be functionally complete before CR1.
1.0.0.CR2/Final => early February 2013 (2-3 weeks after CR1)
1.0.0.Final => late February 2013 (only if required)
Thoughts?
-Jay
13 years
AeroGear IOS-TODO app [update]
by Christos Vasilakis
Hi,
fyi,
TODO app has been updated to use the latest security api so you can now "login".
Further a settings dialog is implemented which gives options to:
a) toggle the use of openshift and user's own todo server, that is he can provide a hostname
b) provide appropriate credentials (username/password)
The release was tagged on github[1]
Thanks,
Christos
[1] https://github.com/aerogear/aerogear-todo-ios/zipball/0.9.0
13 years
Type in Aerogear-android
by Summers Pittman
So I'm poking through the Android code an I come across the Type enum. This is the type of connection/transport/whatever (REST currently is the only one supported, but could be anything in the future) that the Pipe object communicates over. It seems to only be ACTUALLY used in a single factory class and just passed around everywhere else.
Now with all of that said: this currently makes it very hard (conceptually I haven't tried) for third parties to add pipe types without modifying the library itself. IE if we only support Google's cloud push tech then someone who was targetting a Kindle would have to code their own type into the aerogear library itself instead of being able to have that in a separate package.
So is this a feature or a bug?
13 years
