Yesterday I was discussing with Sebi about @objc and how you make a Swift class available in Objective-C
Sebi has one issue, in its Swift protocol he wants to declare longitude/latitude Double and make them optional . Because his protocol is swift only (not inheriting a Obj-c one) he uses @objc and this is when, compiler complains with “Property cannot be marked @objc because its type cannot be represented in Objective-C”.
This issue is well-explain in this stack overflow thread 
One work-around (the one used by Sebi) is to use NSNumber and make then optional.
To echo that issue, yesterday Christos on this thread  gave the example of QueryKit which uses pod subspec coupled with some Objective-C re-write classes (seen as temporary) to bridge the gap Swift to Objective-C fro a Swift first library.
As we’re talking about iOS7 support for our Swift libs there are 2 aspect of it:
- support from obj-c code is one aspect
- dynamic fwk support as expained in this thread  is another one…
All in one, it makes me wonder if it’s worth it… all those hacks in Swift code. Maybe the option we used for ios-push lib i.e.: having obj-c and swift version of the lib would be a better approach.
after  is merged I would like to tag and publish the library in cocoapods. For versioning, I am considering using 1.0.0 (same as in obj-c) with the relative tag 1.0.0-swift, in order not to conflict with the 1.0.0 tag of obj-c counterpart, since they share the same repo.
Today Lukas, Sebastien help me review UPS new UI.
I also did some usability testing yesterday (over dinner with slightly drunk programmers friends of mine).
Here are the results and a bunch of questions for us to discuss:
- Code snippets need a “copy” btn like http://getbootstrap.com/components/
- Descriptions on apps and variants. Can we just remove them? Are they useful?
- "Add a variant" form. There is going to be a validation of the form to make sure connections are correctly set up.
- Variants page . If the user has lots of variants set up, the list would be huge. I am working on solutions, Lukas and Sebastien had very good ideas.
- "Send notification" form has the same problem. Lukas suggested a great solution, to use Multiple select boxes https://select2.github.io/examples.html
- Warnings. Where to show them? How to display them? How to make them disappear once the issue is solve?
- Delete apps or variants takes a lot of time. there is a JIRA about this.
- Add a progress bar to show progress of notifications been sent.
- Add links to documentation everywhere.
- We talked about adding sorting options on the variants list (by name, or by creation date) but it seems that search would be enough. although there was one tester that asked for sorting options.
- It also come to my attention that the name “Variant” is too general. Every non UPS developer I've shown the console asked me “what are variants” and when I explain, they asked me “Why don’t you find a better name that represent “group of devices”?
Lukas mention that a change of wording at this point would be very hard since we have the word “Variant” all over our docs. But maybe for 2.0 we can think of a better way to help the user understand what a Variant is.
Here is the prototype, click around and send feedback :)
WDYT, is it worth exploring further?
On Tue, Jan 20, 2015 at 10:45 AM, GitHub <noreply(a)github.com> wrote:
> Hey there, we're just writing to let you know that you've automatically
> started watching several repositories on GitHub.
> You'll receive notifications for all issues, pull requests, and comments
> that happen inside the repository. If you would like to stop watching any
> of these repositories, you can manage your settings here:
Why not add it on cookbook instead of create a new repo?
Before I continue with UPS console redesign, I want to make sure that everyone has review the new website.
>From your point of view UI is done. What is left to be done:
1- Review overall design and UI again.
2- JS on news and the parts, Lukas is taking care of it.
3- Check if index pages (roadmap, guides, docs and demos) are ok and pointing to the right direction.
4- Text! Review text, make sure there are no typos and dummy texts are fill out.
5- Am I missing something?
You can see this on new-design branch: https://github.com/andresgalante/aerogear.org/tree/new-design