Roadmaps / release dates
by Matthias Wessendorf
Hi,
I am looking at polishing the iOS roadmap and did take a look at the
roadmaps for Android and JS (see [1] and [2]).
Personally I think they are kinda confusing, since they talk about
different releases...
The JS lib talks about:
- 1.0.0.Alpha1 (and says release with AeroGear 1.0.0M5)
- 1.0.0.M1 (and says release with AeroGear 1.0.0M6)
- 1.0.0.M2 (and says release with AeroGear 1.0.0M7)
- 1.0.0.CR1 (and says release with AeroGear 1.0.0CR)
- 1.0.0.Final (and says release with AeroGear 1.0.0Final)
While the Android lib talks about:
- 1.0.0.Alpha1 (and says release with AeroGear 1.0.0M6)
- 1.0.0.Alpha2
- 1.0.0.Beta
- 1.0.0.Final
Not sure if it's helpful if the different libs use different terms
(e.g. Alpha vs. milestone vs. beta)...
What's clear (if I get it right) are the 'raw' release dates for the
'umbrella AeroGear' releases:
- 1.0.0M6 ==> ~ mid Oct 2012
- 1.0.0M7 ==> ~ mid Dec 2012
- 1.0.0CR ==> ~ mid Feb 2013
- 1.0.0Final ==> ~ mid Apr 2013
(basically, every 8 weeks, right ?)
What's also clear (IMO) is that these individual components do NOT
need to match the exact 'release label' of the 'umbrella' AeroGear...
But... not sure if they should at least kinda match a common
'semantic' (e.g. Milestone, Beta etc). I tend to say yes here...
Background:
I want to know the 'labeling' because I am TRYING :) to identify
reasonable pieces for the iOS library, to be released along the
'umbrella' AeroGear release, but got confused since Android has a beta
and JS has 'only' milestones :)
Any thoughts?
-Matthias
[1] http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearAndroid/
[2] http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 3 months
Aerogear-ios and arquillian.
by jose_freitas
Yesterday I clonned aerogear-ios, aerogear-ios-integration and the TODO
application. I was able to install those projects but when running the
aerogear-ios-integration tests, one of the required steps to run it, it's to
deploy the todo.ear in a jboss server.
I was speaking with matzew and it seemed a good idea to integrate the ios
enviroment to work within arquillian, so maybe we could automate steps like
those where you need to deploy the server side of the application to execute
tests.
What do you think? Do you think it would be useful? Is there anyone (besides
me) trying to shoot in that direction?
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-ios-and-arquillian-tp2...
Sent from the aerogear-dev mailing list archive at Nabble.com.
12 years, 3 months
Site review: general feedback
by Matthias Wessendorf
Howdy,
a few questions/suggestions on the site
* HOME page => iOS section
- It says "Download Now (Coming Soon!)", however on CocoaPods we
already have three releases, should we add a link here? Or do we wait
on the DMG format (see [1])?
- Include the github repo for the 'view source' link?
* Download section
- Like above should we add a download link here? Or do we wait on the
DMG format (see [1])?
== Documentation ==
* Specifications
- Should we name this section 'API documentation'? Right now it is
'just' API docs - or do we provide 'specs' here in the future?
=> We could than also break it down into "Client API docs" (e.g.
Android, JS,...) and "Server API docs" (e.g. aerogear-controller)
- Should the link to AeroGear.js point to http://aerogear.github.com
resource ? Or is it correct that it points to a 'self hosted' API doc
?
(I guess at some point we need versioning - yes, we spoke about that
in the past :) )
* Contributing to AeroGear
-> Is this link getting enough visibility ? :)
* Guides (Tutorials, gettings started docs, how-tos)
==> I think we should do some 'grouping' here, folks that are
interested in 'getting started', probably don't care that much about
'How to Handle AeroGear Pull Requests' or 'AeroGear GitHub Workflow'
initially.... IMO looks a bit overloaded (unorganized)...
===> Suggested groups for the "Tutorials, gettings started docs,
how-tos" (sub)section:
* Supported Platforms
AeroGear Browser Support Targets
* Getting Started:
Get Started With HTML5 Mobile Web Development
Deploying HTML5 Applications to Openshift
HTML5 Mobile Quickstart & Archetype Deep Dive
HTML5 + REST Applications
Cordova Setup
Converting an AeroGear HTML5 + REST Web App to a Hybrid App with Apache Cordova
Get Started with Hybrid Application Frameworks
* Contributing to AeroGear
Contributing to AeroGear
AeroGear GitHub Workflow
How to Handle AeroGear Pull Requests
AeroGear JIRA Usage and Guidelines
AeroGear Licensing and Copyright
Greetings,
Matthias
[1] https://issues.jboss.org/browse/AEROGEAR-443
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 3 months
Push!
by Glen Daniels
Hey team,
So thinking a bit about the Android roadmap, and realizing that for
either the Android or the iOS libs to work well (i.e. without killing
the batteries of end-users' phones), we're going to need to do push
integration.
A quick recap - if we want to know when data on the backend has been
updated without a manual "refresh" button, we either have to 1) poll
(which sucks, uses network resources, and doesn't work in the background
on iOS devices) or 2) use push (for which there are specific APIs for
Android and iOS, and there are also "higher level" push service
providers such as Urban Airship).
Yes, polling can be used as a fallback, but for any serious application
that needs live or background updates, push is the only way to go. Yes,
this means another coupling point to "our" server (or at least
contract-compatible servers).
Just wanting to make sure that this is on everyone's radar.
Thoughts/comments?
--Glen
12 years, 3 months
[iOS] AeroGear Integration Tests
by Matthias Wessendorf
Hello,
I worked a bit today on polishing the integration tests for our
AeroGear iOS library ([1]).
I updated the dependency to use the latest AeroGear-iOS version
(0.0.3), which I released today...
I also cleaned up the mess that was here before, b/c of CocoaPods. I
got rid of the workspace, the Pods folder and the Podfile.lock file.
I have updated the README, on how to get started, see [2].
In summary, you need to have CocoaPods installed and need to run it
(at least after initial checkout):
1) After clone, cd into 'AeroGear-iOS-Integration' folder
2) run 'pod install'
3) open the _newly_ generated workspace (open
AeroGear-iOS-Integration.xcworkspace/)
As said in the README, you need a JBoss running, which contains a
clean todo.ear file; here is room for improvement ;-)
Also, if there are things unclear, feel free to fix them - or let's
discuss them here.
Cheers!
Matthias
[1] https://github.com/aerogear/aerogear-ios-integration
[2] https://github.com/aerogear/aerogear-ios-integration/blob/master/README.md
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 3 months
