Docker images for AeroGear
by Bruno Oliveira
Good morning my friends, only because I don't want to hijack the
building thread, I'm opening this one.
For the further docker images I was wondering about the following
structure:
.
├── as7 - Images for JBoss AS7
│ ├── README.md
│ ├── aerogear-simplepush - binaries with the latest stable release
from SimplePush
│ │ └── README.md
│ ├── aerogear-simplepush-dev - compile and run SimplePush from
scratch (the work done by Daniel Bevenius with some changes)
│ │ └── README.md
│ ├── aerogear-unifiedpush - binaries with the latest stable release
from UnifiedPush
│ │ └── README.md
│ └── aerogear-unifiedpush-dev - compile and run UnifiedPush server
from scratch (the first image released here)
│ ├── Dockerfile
│ └── README.md
└── wildfly - Images for Wildfly (with the same goals above)
├── README.md
├── aerogear-simplepush
│ └── README.md
├── aerogear-simplepush-dev
│ └── README.md
├── aerogear-unifiedpush
│ └── README.md
└── aerogear-unifiedpush-dev
└── README.md
What do you think? Is anything missing?
--
abstractj
PGP: 0x84DC9914
12 years
Swift running on iOS 7 / Observations
by Christos Vasilakis
Hi all,
a heads up on my observations during porting our quickstart app [1] (Swift port) and making it compatible to also run on iOS 7 too [2]. Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in the application (and can be observed on the generated app archive [3] ).
A major obstacle faced is that although you can utilise at runtime a form of dynamic version check (e.g. respondsToSelector[] ) to decide to call either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails even when the code-path that instantiates the class is not executed.
Let me give you a concrete example. Here is snippet of code that uses either the new push registration API available in iOS 8 or fails back to the old one if not:
--
if application.respondsToSelector(Selector("registerUserNotificationSettings:")) {
let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | .Sound, categories: nil)
UIApplication.sharedApplication().registerUserNotificationSettings(settings)
UIApplication.sharedApplication().registerForRemoteNotifications()
} else {
UIApplication.sharedApplication().registerForRemoteNotificationTypes( .Badge | .Sound | .Alert)
}
If your Target build SDK is set to ‘Latest (8.0)’ (to avoid compilation error of missing classes) but your deployment target is set to 7.x (to support older versions) and you have some form of dynamic selection on runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with a missing symbol: (note that the code path that instantiates UIUserNotificationSettings is not reached but yet fails at runtime)
--
dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings
Referenced from: /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts
Expected in: /System/Library/Frameworks/UIKit.framework/UIKit
in /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts
--
In contrast, the obj-c version of the same code runs fine on iOS 7.
Apparently this has been observed [4] and some workarounds exist (basically use an objective-c bridge to workaround it, but that is just a ‘hack'). This is to the fact that the obj-c compiler does some form of weak-linking the symbols that are only available on later versions than the deployment target.
I imagine having the same form of issues when trying to utilise a any new iOS 8 class that doesn’t exist on iOS 7. For that matter (at least for the current state of the Swift runtime) i am leading towards not using any hacks to workaround issues on Swift running on iOS 7. I am sure Apple with the current pace of dev will come up with techniques, but let’s not pollute the code for the time being.
Let me know your thoughts.
-
Christos
[1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift
[2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7
[3] http://tinyurl.com/swift-runtime
[4] http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8
12 years
[UPS] What should the Top 3 Most Active Variants shows ?
by Sebastien Blanc
Hi,
I decided to start a new thread after some discussions we had on a previous
thread[1]
Basically, we are talking about this part of the dashboard :
[image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc]
It appeared that is not really clear what we want to show there, as a side
note, the current query behind this is not correct and should change
whatever we decide.
So, what can we show here :
1. Show the most (three) recent active variants (and their # of receivers)
Active means here, the 3 latest variants that sent a Push Message.
The term "receivers" can also be confusing , do we want to show :
1.a : The number of receivers/active tokens that received the last Push
message (i.e : Push Message A sent to 10 people and Push Message B to 5
people, we show 5) ?
1.b : The total number of receivers/actives tokens of this variant (i.e :
Push Message A sent to 10 people and Push Message B to 5 people, we show
15) ?
1.c : The total number of Push Messages sent (i.e : Push Message A sent to
10 people and Push Message B to 5 people, we show 2). ?
2. Show the most active variants (and their # of receivers)
Almost same than 1. but here we look at all the variants even those without
an recent activity.
Here again 1.a/1.b or 1.c applies.
The core question, IMO, is what would be an useful information for the user
?
Sebi
[1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html
12 years
