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
12 years, 11 months
staging.aerogear.org / master unstable for a bit
by Douglas Campos
I'm preparing additional site trackers for RHT's marketing team, and
will need to put it live for them to verify if we're doing it right.
So, master will be unstable for a little bit, so please refrain from
pushing to prod at least for the next two days (I'll try to sort this
sooner)
kthxbai
--
qmx
13 years
"application/json; charset=utf-8" not supported
by Corinne Krych
Hello Guys
Writing code for ProDoctor demo, on client side, I'm using Xcode template
for AGPush which is based on AFNetworking 121
When doing my login request in iOS I bumped into the issue of having
content type set to "application/json; charset=utf-8" whereas on routes
(backend) only "application/json" is set which causes this exception:
[application/json].': java.lang.RuntimeException: AG_CONTROLLER000012: No
Consumer found for Parameter: 'Parameter[type=ENTITY, type=class
org.aerogear.prodoctor.model.SaleAgent]'. The registered Consumers were:
'[JsonConsumer[mediaType=application/json]]'. Please add a Consumer for one
the media types supported by the route: [application/json].
at
org.jboss.aerogear.controller.util.ParameterExtractor.getConsumer(ParameterExtractor.java:152)
[aerogear-controller-1.0.1.jar:1.0.1]
at
org.jboss.aerogear.controller.util.ParameterExtractor.extractArguments(ParameterExtractor.java:70)
[aerogear-controller-1.0.1.jar:1.0.1]
I think we should support both "application/json; charset=utf-8" and
"application/json". /shall we open a JIRA on AeroGear Controller to
support both?
wdyt?
Corinne
13 years
Unified Push Server user management questions
by Hylke Bons
Hi,
It seems that most of us are happy with the wireframes for the Unified
Push Server admin UI. I've used the feedback to make a few small
changes:
https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_pus...
The next step is to look at the the missing features like the user
management and authentication. It would be good to have a discussion
about this, and I have some questions too.
If I understand things correctly, the Push Server can run "standalone"
or as a component in JBoss AS (or something else). So we'll need a UI
for user management when we run standalone, but one that can be disabled
and be plugged in by different existing auth systems that are running on
the server or somewhere else.
Some questions that come to mind:
How is the server bootstrapped? And how is the initial user account
configured? The most essential basic role would be to access the UI and
to configure push notifications (and one to add other (admin) users).
Are there any other roles that we should be considering? Things that
should be disabled for some users?
Thanks,
Hylke
13 years
Push "all inclusive" demo
by Sebastien Blanc
Hey !
We would like to provide, in a quite short delay (coming 2 weeks) a demo
showing all the different bits of the "push" world , meaning :
client | push server | JEE Backend App
We already have the push server (aerogear-unified-push-server) : so we need
a client (iOS and maybe also Android) and a simple JEE backend application.
The backend app will mostly be scaffolded and will use the
aerogear-unified-push-java-client to send messages to the Push Server.
Then of course, we need to think about an idea of the application itself.
It needs to stay really simple, show how we can send selectively and
should be a bit "business" related.
So, I came up with an idea this morning that we can discuss here, of course
if you have any other idea don't hesitate to share it.
Push Demo <https://gist.github.com/sebastienblanc/5755548#introduction>
Introduction
Prodoctor is a company in the health care industry, selling a revolutionary
tensiometer. Their clients are doctors. Prodoctor has several sales agents
all over the United States. At the headquarters, they have their "first
line" sales department doing cold calls all along the day. As soon they
have a concrete lead, they use their Prodoctor Admin app to filter out
available sales Agents available in the lead area. They can then send them
a push notification.
The sales agent receives the notification on their mobile device that a new
lead is available. The agent will handle the lead by "accepting" the
notification informing the other agents that the lead has been processed.
<https://gist.github.com/sebastienblanc/5755548#the-client-app>The client
app
1. The client consist of a list of leads : a lead can be "open" or "in
process", leads "in process" of other sales are not visible.
- optional : when the client tap a lead it appears on a map
1. The client has a status that he can set: STANDBY | WITH_CLIENT |PTO
2. The client has a location
3. The client has an alias
<https://gist.github.com/sebastienblanc/5755548#prodoctor-admin-client>Prodoctor
Admin client
1. The admin client can create a new lead :
- A lead consist of a name and a location
1. The admin client can query for Sales Agents based on :
- Status
- Location
1.
The admin client can assign a lead to a selection (1..n) of sales
agents, this will send out the notifications.
2.
The admin client manage the Sales Agents DB.
13 years, 1 month
Android: Eclipse issue with the "Push"
by Matthias Wessendorf
Hi,
I did a download of the latest Android SDK
(adt-bundle-mac-x86_64-20130522), and did follow our instructions here:
https://github.com/aerogear/aerogear-android/blob/push/README.md
I did the maven-sdk-deployer etc, all good. the branch was compiling with
Maven. Great!
Now, with Eclipse, I did follow these instructions:
http://staging.aerogear.org/docs/guides/GetStartedAndroidEclipse/
But once I finished these steps, I am getting compiler errors. For instance
on the Pipeline.java, I am getting these issues:
import android.app.Fragment;
import android.support.v4.app.FragmentActivity;
import com.google.common.collect.HashMultimap;
import com.google.common.collect.Multimap;
While I think that the android.** related import issues are most likely
related to the fact that this is perhaps now wrong (2.3.3):
http://staging.aerogear.org/docs/guides/img/android_eclipse_import_005.png
But the Google Collections are also not resolving.
I guess the "Import" in Eclipse is not really reflecting the description of
the guava dependency in the pom.xml file.
Besides the google collections, I also noticed that other classes (like "
com.google.android.gms.gcm.GoogleCloudMessaging") are not being resolved.
Is there a way that all these "required" dependencies are picked up
automatically, by the Eclipse IDE? Or do I have to import all
dependencies, by hand ?
Thanks!
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
13 years, 1 month
AeroGearPush iOS device registration error
by Yavuz Selim YILMAZ
Hi all,
After registering an application and iOS variant on my push server following the instructions on https://github.com/aerogear/aerogear-unified-push-server, I am implementing the following method on my iOS client:
// Here we need to register this "Mobile Variant Instance"
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
// we init our "Registration helper:
AGDeviceRegistration *registration =
// WARNING: make sure, you start JBoss with the -b 0.0.0.0 option, to bind on all interfaces
// from the iPhone, you can NOT use localhost :)
[[AGDeviceRegistration alloc] initWithServerURL:[NSURL URLWithString:@"http://10.193.23.8:8080/pushee/"]];
[registration registerWithClientInfo:^(id<AGClientDeviceInformation> clientInfo) {
// Use the Mobile Variant ID, from your register iOS Variant
//
// This ID was received when performing the HTTP-based registration
// with the PushEE server:
[clientInfo setMobileVariantID:@"MY_VARIANT_ID"];
// apply the token, to identify THIS device
[clientInfo setDeviceToken:deviceToken];
// --optional config--
// set some 'useful' hardware information params
UIDevice *currentDevice = [UIDevice currentDevice];
[clientInfo setOperatingSystem:[currentDevice systemName]];
[clientInfo setOsVersion:[currentDevice systemVersion]];
[clientInfo setDeviceType: [currentDevice model]];
} success:^() {
//
} failure:^(NSError *error) {
// did receive an HTTP error from the PushEE server ???
// Let's log it for now:
NSLog(@"PushEE registration Error: %@", error);
}];
}
The registerWithClientInfo call fails with this error:
PushEE registration Error: Error Domain=AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 401" UserInfo=0x1d5522b0 {NSLocalizedRecoverySuggestion=Unauthorized Request, AFNetworkingOperationFailingURLRequestErrorKey=<NSMutableURLRequest http://10.193.23.8:8080/pushee/rest/registry/device>, NSErrorFailingURLKey=http://10.193.23.8:8080/pushee/rest/registry/device, NSLocalizedDescription=Expected status code in (200-299), got 401, AFNetworkingOperationFailingURLResponseErrorKey=<NSHTTPURLResponse: 0x1d549310>}
Do you have any idea/suggestion to solve my problem? Your help is appreciated.
Thanks and regards,
---
Yavuz Selim Yilmaz
SUNY at Buffalo
Computer Science and Engineering
PhD Candidate
13 years, 1 month
