AppCode Aerogear opensource license
by TadeasKriz
Hey guys,
I just wanted to ask, if we have an AppCode [1] open source license for Aerogear. Developing for iOS in Xcode can be quite a pain when one is used to almost perfect IntelliJ IDEA. If we have this license, it would probably really help me speed up iOS test development.
Thanks!
1 - http://www.jetbrains.com/objc/
10 years, 11 months
Request for AGSIMPEPUSH JIRA
by Matthias Wessendorf
Hi,
I think it does make sense to track all the items for SimplePush (server
and client) in a separated JIRA. That way we could have a more
straightforward process of individual release, tracking at the right source
etc.
The integration between UP and SP would be still tracked at AGPUSH, but
that's really just one or two java classes :-)
Motivation:
I think that UP and SP are pretty different. Regarding SP, I think it does
make sense to capture that in a different instance:
* SimplePush works standalone or in combination with WildFly/vert.x
--> different targets, different dependencies, different "envirnoments"
* SimplePush is based on a spec (Moz-specific spec).
--> The server (and the client) should reflect that with different
cycles/releases, to be more fine grain.
* Independency
--> A release of a new version of SimplePush (based on a Netty bug, for
instance), should not be treated in a "Push release", while the UnifiedPush
server has no code changes at all. (vice versa)
For the name: AGSIMPLEPUSH
The AGPUSH will stay to "catch" all the UnifiedPush items.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 11 months
PHP SDK
by Tommy McCarthy
Hey everyone,
I'm at the point now where I believe my PHP SDK code is complete and ready to be reviewed and tested. Of course, if anyone has any feedback for it so far, that would be appreciated as well. The GitHub repo is available here [1]. I've created a JIRA [2] for creating a GitHub repo for the PHP code under the AeroGear account.
If there's anything you'd like to see added, changed, or removed, please let me know! There is a webapp included as a part, which demonstrates a great way to send messages from a web form (or other request)
Thanks!
Tommy
[1] https://github.com/tmccarthy9/aerogear-unified-push-php-client
[2] https://issues.jboss.org/browse/AEROGEAR-1312
10 years, 11 months
Android meeting tomorrow
by Summers Pittman
We got a good turnout last time on no notice so passos and I decided to
give nearly 24 hours notice this time!
We'll be discussing the next few weeks of the Android project. Our
meeting agenda/notes are here:http://oksoclap.com/p/JdijeGCJyQ
We'll kick things off in the clap at 10 EDT.
Summers
10 years, 11 months
[Android] Google's Gradle build tool and AAR
by Summers Pittman
Y'all,
In the last release we had some trouble at the end. People were having
trouble building aerogear-android because the android-sdk-deployer
project had a couple of "small" problems. Mainly there was an issue with
one of the deployers submodules (and it had to be disabled by hand) and
the deployer itself isn't compatible with maven 3.1.0. I don't want to
include in the build instructions for aerogear "download this old
version of Maven and then edit the pom of this third party project".
The easiest way to remove our dependency on the deployer is to start
using Google's gradle build system. The Android SDK has packages for
deploying the necessary repositories so that our build can consume them
and we can use the gradle wrapper to keep our users from having to
install yet more software.
So where does this leave maven? Unfortuantely it is still necessary to
build the apklib file (as far as I know), but it won't be necessary to
actually USE the project anymore.
wdyt?
Summers
10 years, 11 months
AeroGear Build and Dependency Management
by Kris Borchers
As AeroGear.js gets larger and more complex, it makes sense to revisit our build strategy as well as our dependency management strategy since that affects the build.
I was thinking, and after discussing with Luke I believe he agrees, that we should investigate the use of AMD (Asynchronous Module Definition). What this provides for us is:
Better modularization between the pieces of code in AeroGear.js
Better dependency management by specifically defining those dependencies in each module
A better base for our custom build process
I think all of those reasons point to the need for this implementation. That being said, it doesn't come without a cost. We would need to reorganize the repo and modify each file to make it a proper AMD module. This will take time but I think it is time well spent.
I would be glad to hear if anyone has any thoughts or concerns around this.
10 years, 11 months
Browser Support
by Kris Borchers
I would like to propose a couple of things around browser support and get feedback as to how people feel about them.
First, I feel we need to finish our support matrix[1]. I would like to propose the following modifications:
Desktop
IE
I would like to entertain the idea of going to only IE10 support in the near future. We don't have to do it now but according to Global Stat Counter[2], IE9 is on a steady decline (~5% share) since it is being auto-updated to IE10 (~10% share). What's a good share percentage where we can say we should drop support? 2%? 1%? <1%?
Opera => Current - 1
Mobile
Android Browser => Drop 3.2+
Android folks, where are we on 2.3 usage? Still pretty high?
iOS Safari
iOS folks, where are we on 4.3 usage? Can we drop? Especially after release of iOS 7?
Windows Phone IE
Split to WP7.5 and WP8
Keep 7.5 support or just 8
WP8 would be IE10
Mobile Chrome => Current - 1 (Same cycle as Desktop)
Mobile Firefox => Current - 1 (Believe it's same cycle as Desktop)
Second, I would like to expand on an issue we are running into concerning the IE9 support. We have plans to implement multipart upload for Pipeline in the next AGJS release. The only issue is, IE9 does not support XMLHttpRequest2 which means the only way to do REST based file uploads is via an iframe hack which I will not introduce into our code. Until we drop IE9 support, I would like to suggest being able to mark APIs as unsupported in IE9 to keep moving forward with the rest of our modern browsers. Then, once IE9 support is dropped, those notes can be removed.
Thoughts on all points much appreciated.
10 years, 11 months
AeroGear project demo planning
by Jay Balunas
Hi All,
As discussed in the team meeting I wanted to restart discussions around the demos for the project. I know it is long but it is also very important that we agree on our example strategy because it is one of the primary ways that people will learn about AeroGear - especially just starting out. We also need to balance this with the fact that maintenance of multiple examples can be time consuming (src, docs, tests, etc...).
Let me state what I think would be a good model for us at a high level, and then when we come to a consensus about this we can dig into the individual example ideas, specifically around the "showcase" demo (likely in another thread).
All of this is my opinion, not law ;-)
_Showcase Demo_
One larger scale demo that we can cover all (or nearly all) of the planned functionality up to 2.0. There has been several ideas tossed around from stock broker, prodoctor, etc... I don't want to focus on the specific app at this point. Functionality would be additive as we completed it, so the idea would need to be easily "upgraded" as we go.
The app should include all client types as examples (iOS, Android, Hybrid, Web), have a central backend, be deployable to OpenShift, and run on Wildfly/EAP. It would require documentation to discuss complexities and usage for an advanced application, but would not need to cover the bread and butter imo (that is what the quickstart tutorials are for). We would have to commit to long term maintenance of this as well.
There are pros and cons for this type of application. The maintenance and development burden is high. Also we need to be careful not to devote so much time to the application that it takes on a life of its own. I.e. we are not really trying to make a fully competitive stock broker app.
We also want to consider if/how this application would be deployed to an appstore. Depending on the application it may be very appropriate for it to be there, but we'll need to discuss.
Does this sounds acceptable as the scope and starting point for a showcase demo?
_Topic Demos_
I'm not sure about this category of demo yet, but wanted to bring it up. There are use-cases, and functionality that by their definition are beyond the scope of quickstart, and yet we would likely not want to have the showcase demo be the only location we demo the functionality.
The best example of this I can think of is Unified Push. I think we all agree, just the basic setup and requirements around push make it more than a quickstart. With the various servers, configuration, certs, etc... At the same time, we need a demo (both sooner, and simpler) than the showcase demo for the related tutorials, docs, etc...
So this category would be for this type of "topic" - I could see the possibility of some security functionality falling into this too, but I'm not 100% on that.
It would have the same type of requirements as the other demos - docs, tests, maintenance, etc...
Pros would be a more focused demo for specific functionality, cons are another non-trivial demo to maintain.
My personal opinion here would be take it on a case by case basis.
_Quickstarts_
This category sounds like it might be the simplest, but as a whole I think it represents a fairly large amount of work. Imo a quickstart is a focused demo, that highlights 1-2 specific use-cases. JDF has a lot of good definitions and requirements for quick starts that we should consider as well, where they don't conflict. For example build tools, deployment options, etc...
The trick here comes with how to manage and handle all of our different "parts". Do we group by client type, by functionality, etc... So for example, take a security related quickstart. It should show how to integration security across the various client types. Is that 1 quickstart for security, or 3 by client type.
Related to this is the cookbook idea that the Android team is using. Imo I think it is VERY important that all of our client types share a similar approach (cookbook or not). We don't want completely different approaches by client type. If we do group quickstarts (some or all) by client how will we handle common server-side functionality such as that security example above.
All of these items get complicated quickly, but I think we need to nail this down asap because we should start thinking about our quickstart libraries soon imo.
_One off examples_
Another type of example was mentioned in the ML, and that is of one-off examples for presentations, blogs, etc... Imo these are useful, and likely needed some of the time.
I think we should re-use our other examples when possible, but I also know that will not alway work for various reasons. These examples carry no maintenance expectations, and should not be in the AeroGear repositories either imo.
I also think it is possible for one-off examples to "become" quickstarts, but would have to meet the standards for a quickstart as we describe them.
_Repositories_
This is a related topic that I think will likely become its own thread or document, and that is about repository usage for the example types above. In general we need a better policy imo around this topic in general.
* Showcase example: I believe it should have a single repository with /server, /client, and /docs directories as needed. I believe having separate repositories is confusing and leads to clutter. The intent of the showcase app is to demo how everything integrates in one place, and should be easily accessed.
* Topic examples: I believe these should have a similar requirement as the showcase example. The point of the topic example is to cover a specific topic, not specific individual clients.
* Quickstart examples: This again gets complicated, and may depend on the way we choose to group them. However we group them, I think we should have a limited number of *-quickstart repositories, we should not have a repo for each quickstart. We'll need to discuss this as we discuss quickstart planning in general.
* One off examples: should not be in AeroGear's repository at all. Imo, if we aren't committing to maintain it we should not have it our repository.
_Forge and JBDS_
We also need to discuss how any of these examples relate to forge and JBDS efforts. At the very least, imo, some of our quickstarts should be based on scaffolding, and tooling. Imo many of the example (where possible) should be compatible with forge, and JBDS.
Not all examples would need to be compatible. Obviously that does not apply to iOS, and we would need to balance the effort required on a case-by-case basis for others. It just might not make sense or have a different target than forge or JBDS. That is fine, I don't want to use this as a handicap, but we should be considering both of these as we go.
----------
Again, I don't want this thread to break down into specific use-case discussions, I want us to discuss the example strategies for the project, then we can kick off separate thread for break down specific examples, and plans for them.
-Jay
10 years, 11 months
