11:20 p.m.
Summers and I tossed around the idea last week to create a 'root document' how to
build AeroGear android lib and apps.
The idea is write a simple document that looks like ActionBar Sherlock doc instead of
having a huge doc with lots of repeated setup, have a setup docs which branch from there
Publish it on aerogear.org and link all others (like README) with it
My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
wdyt?
-- Daniel Passos
9 a.m.
Hello Daniel
I really buy into your idea.
We definitively need more consistent documentation on AeroGear features with concrete and
simple exemple (like we started in cookbook).
Let's refactor our documentation together and meake suure we go in the same
direction.
See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per
category/features: core, push, security, offline/sync. We could have a general description
of what the features is, some link to specs etc..
Then the sample part. Each sample/recipe(from cookbook) should be well documented and
follow a similar template like you gist shown it. I've done similar with iOS-cookbook.
One central readme [1] which list all recipes. Each recipes [2] has is own documentation
following the same template. We ca work on unifying the template. I like prerequisites
section, install/build section common to both, you miss a short description of the app and
some ui flow with pictures would be nice and then a last sec ion we we explain the main
fatures we want ot demo.
A couple of questions on implementation though:
- Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the
sample documentation should belong to the cookbook repo.
- How are we going to publish read me info from cookbook into aerogear.org repo? a build
or some sort of automation will be good.
++
Corinne
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
[1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
[2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
Summers and I tossed around the idea last week to create a 'root
document' how to build AeroGear android lib and apps.
The idea is write a simple document that looks like ActionBar Sherlock doc instead of
having a huge doc with lots of repeated setup, have a setup docs which branch from there
Publish it on aerogear.org and link all others (like README) with it
My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
wdyt?
-- Daniel Passos
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:33 p.m.
On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
Hello Daniel
I really buy into your idea.
We definitively need more consistent documentation on AeroGear features
with concrete and simple exemple (like we started in cookbook).
The idea is clean up our documentation, write a UNIQUE document explaining
how to build our lib and apps. Looks like
ActionBarSherlock<http://actionbarsherlock.com/usage.html>
- Prereq
- Build
- Usage
In all README we will link for this document (on ag.org) and add specific
things for the app
Let's refactor our documentation together and meake suure we go in the same
direction.
See Hylke thread on it [1]. As suggested by Hylke, let's group our
documentation per category/features: core, push, security, offline/sync. We
could have a general description of what the features is, some link to
specs etc..
+1 for reorganize this
Then the sample part. Each sample/recipe(from cookbook) should be well
documented and follow a similar template like you gist shown it.
I've done
similar with iOS-cookbook. One central readme [1] which list all recipes.
Each recipes [2] has is own documentation following the same template. We
ca work on unifying the template. I like prerequisites section,
install/build section common to both, you miss a short description of the
app and some ui flow with pictures would be nice and then a last sec ion we
we explain the main fatures we want ot demo.
The root document is not to explain how to use our features. It’s for
explain how to build our libs and apps.
We don’t have one central README and other specific for cookbook looks like
iOS, because for Android we have only one cookbook app. This application
has all our features. For each feature we have one activity (screen). This
makes the explanation very simple and focus on this feature. Each activity
(screens) explain one feature and each feature has a usage guide on the
ag.org ( <http://aerogear.org/docs/guides/aerogear-android/>
http://aerogear.org/docs/guides/aerogear-android/))
A couple of questions on implementation though:
- Instead of just having links to cookbook, how can we embed in
asciidoc
or markdown? the sample documentation should belong to the cookbook repo.
- How are we going to publish read me info from cookbook into aerogear.orgrepo? a build
or some sort of automation will be good.
I think those questions have been answered above.
++
Corinne
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
[1]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
[2]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
> Summers and I tossed around the idea last week to create a 'root
document' how to build AeroGear android lib and apps.
>
> The idea is write a simple document that looks like ActionBar Sherlock
doc instead of having a huge doc with lots of repeated setup, have a setup
docs which branch from there
>
> Publish it on aerogear.org and link all others (like README) with it
>
> My draft for it is here:
https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
>
> wdyt?
>
> -- Daniel Passos
>
> _______________________________________________
> 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
4:05 p.m.
Well, That is what we have today and what we want to follow
<#>Android Documentations <#> Root document
A documentation explain how to build lib and app
<#>README
A link for root document and add specific things for conf/run app
<#>Usage Guide
For each feature we have a document explaining how to use it on the site.
We don’t add any explanation of how to use a feature in the README
<#>Cookbook
We have only one app to show for community see how to our feature works. We
have one activity per usage guide
<#> Feature table
I love corinne idea for put table feature on README but I like to move it
for ag lib instead cookbook
On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos <daniel(a)passos.me> wrote:
On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych
<corinnekrych(a)gmail.com>
wrote:
Hello Daniel
>
> I really buy into your idea.
> We definitively need more consistent documentation on AeroGear features
> with concrete and simple exemple (like we started in cookbook).
>
The idea is clean up our documentation, write a UNIQUE document explaining
how to build our lib and apps. Looks like
ActionBarSherlock<http://actionbarsherlock.com/usage.html>
- Prereq
- Build
- Usage
In all README we will link for this document (on ag.org) and add specific
things for the app
Let's refactor our documentation together and meake suure we go in the
> same direction.
> See Hylke thread on it [1]. As suggested by Hylke, let's group our
> documentation per category/features: core, push, security, offline/sync. We
> could have a general description of what the features is, some link to
> specs etc..
>
+1 for reorganize this
Then the sample part. Each sample/recipe(from cookbook) should be well
> documented and follow a similar template like you gist shown it. I've done
> similar with iOS-cookbook. One central readme [1] which list all recipes.
> Each recipes [2] has is own documentation following the same template. We
> ca work on unifying the template. I like prerequisites section,
> install/build section common to both, you miss a short description of the
> app and some ui flow with pictures would be nice and then a last sec ion we
> we explain the main fatures we want ot demo.
>
The root document is not to explain how to use our features. It’s for
explain how to build our libs and apps.
We don’t have one central README and other specific for cookbook looks
like iOS, because for Android we have only one cookbook app. This
application has all our features. For each feature we have one activity
(screen). This makes the explanation very simple and focus on this feature.
Each activity (screens) explain one feature and each feature has a usage
guide on the ag.org ( <http://aerogear.org/docs/guides/aerogear-android/>
http://aerogear.org/docs/guides/aerogear-android/))
A couple of questions on implementation though:
> - Instead of just having links to cookbook, how can we embed in asciidoc
> or markdown? the sample documentation should belong to the cookbook repo.
> - How are we going to publish read me info from cookbook into
> aerogear.org repo? a build or some sort of automation will be good.
>
I think those questions have been answered above.
> ++
> Corinne
> [1]
>
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
> [1]
> https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
> [2]
> https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
>
> On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
>
> > Summers and I tossed around the idea last week to create a 'root
> document' how to build AeroGear android lib and apps.
> >
> > The idea is write a simple document that looks like ActionBar Sherlock
> doc instead of having a huge doc with lots of repeated setup, have a setup
> docs which branch from there
> >
> > Publish it on aerogear.org and link all others (like README) with it
> >
> > My draft for it is here:
> https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
> >
> > wdyt?
> >
> > -- Daniel Passos
> >
> > _______________________________________________
> > 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
>
4:40 p.m.
On Dec 13, 2013, at 4:05 PM, Daniel Passos <daniel(a)passos.me> wrote:
Well, That is what we have today and what we want to follow
Android Documentations
Root document
A documentation explain how to build lib and app
README
A link for root document and add specific things for conf/run app
Usage Guide
For each feature we have a document explaining how to use it on the site. We don’t add
any explanation of how to use a feature in the README
Cookbook
We have only one app to show for community see how to our feature works. We have one
activity per usage guide
Because of the nature of iOS app, we use storyboard (no UI code) so we can concentrate on
AG app code.
We add a bit of fun by defining 'fun' app.
I think we don't have to stick exactly to the same for the recipes. Both ways are
fine, one single objective: demo AG code, straight to the point.
Feature table
I love corinne idea for put table feature on README but I like to move it for ag lib
instead cookbook
Agreed
We could move this table in web site documetation and add a link on cookbook readme to
it.
https://issues.jboss.org/browse/AGIOS-141
Once you've completed your Android documentation, we can start iOS one and stick close
to yours for the template.
On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos <daniel(a)passos.me> wrote:
On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
Hello Daniel
I really buy into your idea.
We definitively need more consistent documentation on AeroGear features with concrete and
simple exemple (like we started in cookbook).
The idea is clean up our documentation, write a UNIQUE document explaining how to build
our lib and apps. Looks like ActionBarSherlock
• Prereq
• Build
• Usage
In all README we will link for this document (on ag.org) and add specific things for the
app
Let's refactor our documentation together and meake suure we go in the same
direction.
See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per
category/features: core, push, security, offline/sync. We could have a general description
of what the features is, some link to specs etc..
+1 for reorganize this
Then the sample part. Each sample/recipe(from cookbook) should be well documented and
follow a similar template like you gist shown it. I've done similar with iOS-cookbook.
One central readme [1] which list all recipes. Each recipes [2] has is own documentation
following the same template. We ca work on unifying the template. I like prerequisites
section, install/build section common to both, you miss a short description of the app and
some ui flow with pictures would be nice and then a last sec ion we we explain the main
fatures we want ot demo.
The root document is not to explain how to use our features. It’s for explain how to
build our libs and apps.
We don’t have one central README and other specific for cookbook looks like iOS, because
for Android we have only one cookbook app. This application has all our features. For each
feature we have one activity (screen). This makes the explanation very simple and focus on
this feature. Each activity (screens) explain one feature and each feature has a usage
guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/))
A couple of questions on implementation though:
- Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the
sample documentation should belong to the cookbook repo.
- How are we going to publish read me info from cookbook into aerogear.org repo? a build
or some sort of automation will be good.
I think those questions have been answered above.
++
Corinne
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
[1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
[2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
> Summers and I tossed around the idea last week to create a 'root document'
how to build AeroGear android lib and apps.
>
> The idea is write a simple document that looks like ActionBar Sherlock doc instead
of having a huge doc with lots of repeated setup, have a setup docs which branch from
there
>
> Publish it on aerogear.org and link all others (like README) with it
>
> My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
>
> wdyt?
>
> -- Daniel Passos
>
> _______________________________________________
> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:26 a.m.
After a lot of drafts:
The Root Document ideia: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
The README example: https://gist.github.com/danielpassos/2fe51449fc5547b3e65f
wdyt?
--
Daniel Passos
On December 13, 2013 at 1:41:00 PM, Corinne Krych (corinnekrych(a)gmail.com) wrote:
On Dec 13, 2013, at 4:05 PM, Daniel Passos <daniel(a)passos.me> wrote:
Well, That is what we have today and what we want to follow
Android Documentations
Root document
A documentation explain how to build lib and app
README
A link for root document and add specific things for conf/run app
Usage Guide
For each feature we have a document explaining how to use it on the site. We don’t add
any explanation of how to use a feature in the README
Cookbook
We have only one app to show for community see how to our feature works. We have one
activity per usage guide
Because of the nature of iOS app, we use storyboard (no UI code) so we can concentrate on
AG app code.
We add a bit of fun by defining 'fun' app.
I think we don't have to stick exactly to the same for the recipes. Both ways are
fine, one single objective: demo AG code, straight to the point.
Feature table
I love corinne idea for put table feature on README but I like to move it for ag lib
instead cookbook
Agreed
We could move this table in web site documetation and add a link on cookbook readme to it.
https://issues.jboss.org/browse/AGIOS-141
Once you've completed your Android documentation, we can start iOS one and stick close
to yours for the template.
On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos <daniel(a)passos.me> wrote:
On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
Hello Daniel
I really buy into your idea.
We definitively need more consistent documentation on AeroGear features with concrete and
simple exemple (like we started in cookbook).
The idea is clean up our documentation, write a UNIQUE document explaining how to build
our lib and apps. Looks like ActionBarSherlock
• Prereq
• Build
• Usage
In all README we will link for this document (on ag.org) and add specific things for the
app
Let's refactor our documentation together and meake suure we go in the same
direction.
See Hylke thread on it [1]. As suggested by Hylke, let's group our documentation per
category/features: core, push, security, offline/sync. We could have a general description
of what the features is, some link to specs etc..
+1 for reorganize this
Then the sample part. Each sample/recipe(from cookbook) should be well documented and
follow a similar template like you gist shown it. I've done similar with iOS-cookbook.
One central readme [1] which list all recipes. Each recipes [2] has is own documentation
following the same template. We ca work on unifying the template. I like prerequisites
section, install/build section common to both, you miss a short description of the app and
some ui flow with pictures would be nice and then a last sec ion we we explain the main
fatures we want ot demo.
The root document is not to explain how to use our features. It’s for explain how to
build our libs and apps.
We don’t have one central README and other specific for cookbook looks like iOS, because
for Android we have only one cookbook app. This application has all our features. For each
feature we have one activity (screen). This makes the explanation very simple and focus on
this feature. Each activity (screens) explain one feature and each feature has a usage
guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/))
A couple of questions on implementation though:
- Instead of just having links to cookbook, how can we embed in asciidoc or markdown? the
sample documentation should belong to the cookbook repo.
- How are we going to publish read me info from cookbook into aerogear.org repo? a build
or some sort of automation will be good.
I think those questions have been answered above.
++
Corinne
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
[1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
[2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
> Summers and I tossed around the idea last week to create a 'root document'
how to build AeroGear android lib and apps.
>
> The idea is write a simple document that looks like ActionBar Sherlock doc instead
of having a huge doc with lots of repeated setup, have a setup docs which branch from
there
>
> Publish it on aerogear.org and link all others (like README) with it
>
> My draft for it is here: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
>
> wdyt?
>
> -- Daniel Passos
>
> _______________________________________________
> 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
_______________________________________________
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
10:34 a.m.
In your build instruction since you're mentioning Gradle in the Usage section and not
any more in the Build section, I think it will be nice to add a note saying about Gradle
usage and how it is supported (or not) in AG.
Format looks good to me. Table of demo apps +1
++
Corinne
On Dec 18, 2013, at 10:26 AM, Daniel Passos <daniel(a)passos.me> wrote:
After a lot of drafts:
The Root Document ideia: https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
The README example: https://gist.github.com/danielpassos/2fe51449fc5547b3e65f
wdyt?
--
Daniel Passos
On December 13, 2013 at 1:41:00 PM, Corinne Krych (corinnekrych(a)gmail.com) wrote:
>
> On Dec 13, 2013, at 4:05 PM, Daniel Passos <daniel(a)passos.me> wrote:
>
> > Well, That is what we have today and what we want to follow
> >
> > Android Documentations
> >
> > Root document
> >
> > A documentation explain how to build lib and app
> >
> > README
> >
> > A link for root document and add specific things for conf/run app
> >
> > Usage Guide
> >
> > For each feature we have a document explaining how to use it on the site. We
don’t add any explanation of how to use a feature in the README
> >
> > Cookbook
> >
> > We have only one app to show for community see how to our feature works. We have
one activity per usage guide
>
> Because of the nature of iOS app, we use storyboard (no UI code) so we can
concentrate on AG app code.
> We add a bit of fun by defining 'fun' app.
> I think we don't have to stick exactly to the same for the recipes. Both ways are
fine, one single objective: demo AG code, straight to the point.
>
> >
> > Feature table
> >
> > I love corinne idea for put table feature on README but I like to move it for ag
lib instead cookbook
>
> Agreed
> We could move this table in web site documetation and add a link on cookbook readme
to it.
> https://issues.jboss.org/browse/AGIOS-141
> Once you've completed your Android documentation, we can start iOS one and stick
close to yours for the template.
>
> >
> >
> >
> > On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos <daniel(a)passos.me> wrote:
> > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
> >
> >
> >
> > Hello Daniel
> >
> > I really buy into your idea.
> > We definitively need more consistent documentation on AeroGear features with
concrete and simple exemple (like we started in cookbook).
> >
> >
> > The idea is clean up our documentation, write a UNIQUE document explaining how
to build our lib and apps. Looks like ActionBarSherlock
> >
> > • Prereq
> > • Build
> > • Usage
> > In all README we will link for this document (on ag.org) and add specific things
for the app
> >
> >
> >
> > Let's refactor our documentation together and meake suure we go in the same
direction.
> > See Hylke thread on it [1]. As suggested by Hylke, let's group our
documentation per category/features: core, push, security, offline/sync. We could have a
general description of what the features is, some link to specs etc..
> >
> >
> > +1 for reorganize this
> >
> >
> >
> > Then the sample part. Each sample/recipe(from cookbook) should be well
documented and follow a similar template like you gist shown it. I've done similar
with iOS-cookbook. One central readme [1] which list all recipes. Each recipes [2] has is
own documentation following the same template. We ca work on unifying the template. I like
prerequisites section, install/build section common to both, you miss a short description
of the app and some ui flow with pictures would be nice and then a last sec ion we we
explain the main fatures we want ot demo.
> >
> >
> > The root document is not to explain how to use our features. It’s for explain
how to build our libs and apps.
> >
> > We don’t have one central README and other specific for cookbook looks like iOS,
because for Android we have only one cookbook app. This application has all our features.
For each feature we have one activity (screen). This makes the explanation very simple and
focus on this feature. Each activity (screens) explain one feature and each feature has a
usage guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/))
> >
> >
> >
> > A couple of questions on implementation though:
> > - Instead of just having links to cookbook, how can we embed in asciidoc or
markdown? the sample documentation should belong to the cookbook repo.
> > - How are we going to publish read me info from cookbook into aerogear.org repo?
a build or some sort of automation will be good.
> >
> >
> > I think those questions have been answered above.
> >
> > ++
> > Corinne
> > [1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
> > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
> > [2]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
> >
> > On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
> >
> > > Summers and I tossed around the idea last week to create a 'root
document' how to build AeroGear android lib and apps.
> > >
> > > The idea is write a simple document that looks like ActionBar Sherlock doc
instead of having a huge doc with lots of repeated setup, have a setup docs which branch
from there
> > >
> > > Publish it on aerogear.org and link all others (like README) with it
> > >
> > > My draft for it is here:
https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
> > >
> > > wdyt?
> > >
> > > -- Daniel Passos
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:57 a.m.
Well, the AG Lib is a maven project so for build it you have only one
option: Maven. We’ll start ship AG lib in 2 diferents formats
-
apklib<https://developer.android.com/tools/projects/index.html#Library...
using in your maven project
- aar <http://tools.android.com/tech-docs/new-build-system/user-guide>(as
experimental) to using in your gradle project
--
Daniel Passos
On December 18, 2013 at 7:34:52 AM, Corinne Krych
(corinnekrych@gmail.com<//corinnekrych(a)gmail.com>)
wrote:
In your build instruction since you're mentioning Gradle in the Usage
section and not any more in the Build section, I think it will be nice to
add a note saying about Gradle usage and how it is supported (or not) in
AG.
Format looks good to me. Table of demo apps +1
++
Corinne
On Dec 18, 2013, at 10:26 AM, Daniel Passos <daniel(a)passos.me> wrote:
After a lot of drafts:
The Root Document ideia:
https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
The README example:
https://gist.github.com/danielpassos/2fe51449fc5547b3e65f
wdyt?
--
Daniel Passos
On December 13, 2013 at 1:41:00 PM, Corinne Krych (corinnekrych(a)gmail.com)
wrote:
>
> On Dec 13, 2013, at 4:05 PM, Daniel Passos <daniel(a)passos.me> wrote:
>
> > Well, That is what we have today and what we want to follow
> >
> > Android Documentations
> >
> > Root document
> >
> > A documentation explain how to build lib and app
> >
> > README
> >
> > A link for root document and add specific things for conf/run app
> >
> > Usage Guide
> >
> > For each feature we have a document explaining how to use it on the
site.
We don’t add any explanation of how to use a feature in the README
> >
> > Cookbook
> >
> > We have only one app to show for community see how to our feature
works.
We have one activity per usage guide
>
> Because of the nature of iOS app, we use storyboard (no UI code) so we
can
concentrate on AG app code.
> We add a bit of fun by defining 'fun' app.
> I think we don't have to stick exactly to the same for the recipes. Both
ways are fine, one single objective: demo AG code, straight to the point.
>
> >
> > Feature table
> >
> > I love corinne idea for put table feature on README but I like to move
it
for ag lib instead cookbook
>
> Agreed
> We could move this table in web site documetation and add a link on
cookbook
readme to it.
> https://issues.jboss.org/browse/AGIOS-141
> Once you've completed your Android documentation, we can start iOS one
and
stick close to yours for the template.
>
> >
> >
> >
> > On Fri, Dec 13, 2013 at 12:33 PM, Daniel Passos <daniel(a)passos.me>
wrote:
> > On Tue, Dec 10, 2013 at 6:00 AM, Corinne Krych
<corinnekrych(a)gmail.com>
wrote:
> >
> >
> >
> > Hello Daniel
> >
> > I really buy into your idea.
> > We definitively need more consistent documentation on AeroGear
features
with concrete and simple exemple (like we started in cookbook).
> >
> >
> > The idea is clean up our documentation, write a UNIQUE document
explaining
how to build our lib and apps. Looks like ActionBarSherlock
> >
> > • Prereq
> > • Build
> > • Usage
> > In all README we will link for this document (on ag.org) and add
specific
things for the app
> >
> >
> >
> > Let's refactor our documentation together and meake suure we go in the
same direction.
> > See Hylke thread on it [1]. As suggested by Hylke, let's
group our
documentation per category/features: core, push, security, offline/sync.
We
could have a general description of what the features is, some link to
specs etc..
> >
> >
> > +1 for reorganize this
> >
> >
> >
> > Then the sample part. Each sample/recipe(from cookbook) should be well
documented and follow a similar template like you gist shown it. I've done
similar with iOS-cookbook. One central readme [1] which list all recipes.
Each recipes [2] has is own documentation following the same template. We
ca work on unifying the template. I like prerequisites section,
install/build section common to both, you miss a short description of the
app and some ui flow with pictures would be nice and then a last sec ion we
we explain the main fatures we want ot demo.
> >
> >
> > The root document is not to explain how to use our features. It’s for
explain how to build our libs and apps.
> >
> > We don’t have one central README and other specific for cookbook looks
like iOS, because for Android we have only one cookbook app. This
application has all our features. For each feature we have one activity
(screen). This makes the explanation very simple and focus on this feature.
Each activity (screens) explain one feature and each feature has a usage
guide on the ag.org (http://aerogear.org/docs/guides/aerogear-android/))
> >
> >
> >
> > A couple of questions on implementation though:
> > - Instead of just having links to cookbook, how can we embed in
asciidoc
or markdown? the sample documentation should belong to the
cookbook repo.
> > - How are we going to publish read me info from cookbook
into
aerogear.org repo? a build or some sort of automation will be good.
> >
> >
> > I think those questions have been answered above.
> >
> > ++
> > Corinne
> > [1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Website-restructur...
> > [1]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/README.md
> > [2]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
> >
> > On Dec 9, 2013, at 11:20 PM, Daniel Passos <daniel(a)passos.me> wrote:
> >
> > > Summers and I tossed around the idea last week to create a 'root
document' how to build AeroGear android lib and apps.
> > >
> > > The idea is write a simple document that looks like ActionBar
Sherlock doc instead of having a huge doc with lots of repeated setup, have
a setup docs which branch from there
> > >
> > > Publish it on aerogear.org and link all others (like README) with it
> > >
> > > My draft for it is here:
https://gist.github.com/danielpassos/4b4e694c1c71473b4f59
> > >
> > > wdyt?
> > >
> > > -- Daniel Passos
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
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
3775
days inactive
3784
days old
7 comments
2 participants
participants (2)
-
Corinne Krych -
Daniel Passos