UPS unit tests
by Erik Jan de Wit
Hi,
The database unit tests of the UPS contain a lot of setup code as setting up the database is done within the test method. I’m proposing to remove this ‘noise’ from the test and put it in a separate file. Another thing that is setting up the dao's, when we use arquillian weld container we can use injection in our tests to further reduce the boilerplate, have a look at an example:
https://github.com/edewit/aerogear-unifiedpush-server/blob/4bb63adce319df...
If you like I could do this for all these tests.
Cheers,
Erik Jan
11 years, 1 month
Sync Notes / Early issues
by Summers Pittman
Summary (From my POV on Android):
Sync Server doesn't use any authentication or ownership tracking.
GCM-XMPP bridge needs a lot of love
We need to define a different connection lifecycle for GCM.
The in memory data store is problematic because clients and servers
must be stopped and started atomically
We might want to show off syncing different types of documents (i.e.
a todo list in addition to Luke's hobbies)
Fixing the GCM bridge is probably a couple weeks of work to get it
"solid". That will be a good alpha.1/preview to show off.
So Last week I put together a demo to try and stretch the legs of the
Android Sync Client APIs.
It crashes, a lot. Which is a bit to be expected as the code hasn't
really be used for, well, anything until now. We will get to that though.
Here is the alpha.1 workflow. You log in and you see your docs. You can
edit your docs or you can create new ones. In the future I would like
to add sharing and collaboration but that's the future. Here's a flow
chart for the visual thinkers out there (with real screen caps from the
real working app)
*
https://docs.google.com/drawings/d/145XuutxR1yY0k81w2nIIy980itDIwxzH_gcDE...
To make all of this work I use a RESTful server which tracks a user's
username and the documents they "own". The sync server just syncs and
serves the document you ask for. It has no authentication and any doc
you ask for you get to be an editor on.
The client uses the GCM XMPP¹ bridge I wrote while drunk on the side of
a mountain and it shows. The biggest issue is that shadows for
documents aren't getting created right sometimes because either 1) the
client or server bounced and the data stores are no long synced or 2)
the server thinks there are more clients than actually are connected.
GCM-XMPP doesn't supply connection/disconnection information like
WebSockets will. Instead we just know that some messages we sent a
while ago weren't delivered. We need to figure out how to turn this
into connection and disconnection information in a way that lets the
shadows exist correctly.
Another issue that needs to be addressed is using something other than
the Luke Skywalker hobbies document. (Or maybe showing off multiple
document types in the demo). I'm up for suggestions.
Anyway, the principles (diff sync with a restful documentId broker for
security) are sound. I think we can buff out some implementation
details and have a good alpha/preview/poc release in the few weeks -> 1
month time frame for Android and the sync server.
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
Foot Notes:
1. The sync server has two client connection technologies : WebSockets
and GCM-XMPP. Android uses the GCM-XMPP because it takes all of the
nasty connection handling code and gives let's Android deal with it.
More info here : https://developer.android.com/google/gcm/ccs.html
11 years, 1 month
Properties for Sync Client API
by Summers Pittman
What data is needed for instanciating a sync client on each of the
platforms?
On Android we need the clientId (for the sync server) and the senderId
(for the GCM-XMPP bridge).
I know that for netty/websockets we also need a URL for the server but
not the sender id. Am I missing anything else?
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
11 years, 1 month
aerogear-push and sticky-session
by Kleber Rocha
Hello,
There any way to use aerogear-push with mod_cluster and sticky-session?
I configured a wildfly and mod_cluster, with two nodes, but session is lost
when changed the node.
Thanks
11 years, 1 month
[RFC] UPS DB Migration Strategy
by Douglas Campos
Howdy!
I've been envisioning a plan for UPS migrations, and would like to get
some feedback from the community, so here it is:
When there are model changes, it's kinda annoying to generate the sql
migration files. This is one of the reasons Erik Jan de Wit started
working to add liquibase to the project, allowing for seamless
migrations.
I'd like to build upon Erik's initial work and prepare a `ups-migrator`
distribution:
ups-migrator-VERSION.zip
`--ups-migrator.jar
`--ups-migrator-postgresql.properties
`--ups-migrator-mysql.properties
`--lib
`-- <jdbc drivers>
`-- <liquibase & deps>
This migrator tool can be run with plain `java -jar` and deals with all
the migrations needed up to `VERSION`, which means we would need only
one migrator tool for both 1.0.x and HEAD.
Thoughts? Comments?
--
qmx
11 years, 1 month
Parallel support for a Cocoapods Swift/Obj-c library
by Christos Vasilakis
Hi team,
a little heads up on an issue that I‘ve been looking the last days, on how to proper support both an Obj-C and a Swift library (in-parallel) on Cocoapods. There was a discussion on the cocoapods issues tracker[1] basically around two ideas:
a) being a separate project, with a new name plus utilising Swift specific language propers.
b) having one project, utilising cocoapods subspec mechanism to include specific files per spec requested. In a nutshell users will employ in their Podfile something of a form:
—
pod “MyFooBarLibrary/Objc’ (objective-c)
or
pod “ MyFooBarLibrary/Swift’ (Swift)
—
Solution (b) was intrigued and went on to discover more, since I haven’t used before the subspec mechanism and was a good opportunity to learn. The issue mentioned two projects, QueryKit[2] and ReactiveCocoa[3] (their Swift branch) that utilise this mechanism, so I dive in trying to see how it works.
My realisations:
a) both projects are designed with ‘Swift first’ approach, employing _some_ 'Objective-C code’ to ease the interaction in a mixed project e.g Objective-C code calling the ‘Swift’ library, see [4] where the author describes more details on this.
b) since ‘Swift first’, both produce frameworks where they can be integrated either in objective-c or swift language projects, no ‘static-library’ targets.
c) both are designed for iOS >= 8.0
To make it short and from my understanding, the projects are _not_ designed around the idea of: take either the Objective-C or the Swift port in you project, but instead employ an Objective-C subspec to “ease” the interaction in a mixed environment, aka Objective-C code calling the Swift library.
Regardless and to better understand, I did some testing with our push-sdk:
a) having a single Swift Project employing both the objective-c code and Swift code
b) having a .workspace with a) Obj-c xcodeproj, b) Swift xcodeproj.
In both cases, this mixed approaches, at the end caused issues and wasn’t able to generate a proper solution. Issues around a) cocoapods 'pod install’ steps, b) tests on the library are done with two different dependencies c) various other integration issues…
It’s my sense, the most clean way is to go with separate libraries, that is solution (a) described above (a solution proposed also from @orta [5]) This has the added benefit of cleaner 'logistics’ that is: commit history, releases, static/framework library generations etc etc.
But there is one issue if we go with separate approach: _cocoapods naming_, that is how to properly separate between the two.
Currently searching for AeroGear-Push in cocoapods.org site we get the following:
In my cocoapods PR [6] I went with the approach to name the ‘Swift’ equivalent library as 'AeroGear-Push-Swift’, so the same searching above will reveal:
—
AeroGear-Push
AeroGear-Push-Swift
—
Some of you have already noticed, that the ‘hyphen’ character as a podspec name doesn’t work well with a Swift Project, cause the podspec name is used as the name of the final #import statement the user does. That is the following import statement doesn’t work:
—
import AeroGear-Push-Swift
—
Solving this, there are two approaches:
a) rename both library podspecs : Objective-C to -> AeroGearPush and Swift to -> AeroGearPushSwift
b) continue the same naming, but use the new ‘module_name’ podspec directive in the Swift project(added in cocoapods [6]) to specify the final module name the user will use on the import. That is the approach I have taken in my PR[6]
If we go with (b) the entries will look like this:
——
Obj-c: (no changes needed)
Podfile: pod 'AeroGear-Push’
Class: #import <AeroGearPush/AeroGearPush.h>
Swift:
Podfile: pod 'AeroGear-Push-Swift’
Class: import “AeroGearPush” (notice _no_ ‘Swift’ postfix is needed cause of the ‘module_name’ override)
——
I am fine with both albeit more towards (b) mostly not to break existing ‘pod installs’ the users may use and since support with the ‘module_name’ directive is provided from cocoapods. Current PR[6] goes with this approach.
Let me know your comments and suggestions
Thanks
Christos
[1] https://github.com/CocoaPods/CocoaPods/issues/3016
[2] https://github.com/QueryKit/QueryKit
[3] https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development
[4] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100
[5] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109
[6] https://github.com/aerogear/aerogear-ios-push/pull/41
[7] http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/
11 years, 1 month
