Present Company | San Francisco | Founding iOS & Java engineer[s] | https://present.co/
We’re building Present, an innovative social network just for women!
We’d like to hire experienced iOS and Java server engineers. Our iOS app is written in Swift. For the server role, experience with our chosen technologies is a plus: App Engine (Java), Guice, Guava, Objectify, Protocol Buffers, Docker.
Our team is almost 80% women and has experience at Square (former CTO), Google, and Facebook: https://present.co/join.html
Send your LinkedIn and/or GitHub to hello@present.co. Let’s be Present!
It’s important for our community to authenticate that our users actually identify as women so we leverage FB to confirm that the women are real people. We appreciate the feedback and are already thinking of using other ways to sign up!
Present enables you to start, discover and participate in location-based conversations in real time. There's really nothing like it, let alone a network just for women!
Present Company | Founding Engineer (iOS, Java server) | San Francisco | https://present.co/
We’re building Present, a local social network just for women. By enabling women to discover each other and chat based on location, time, and shared interests, we’ll strengthen local communities and make the world—the real world in particular—a better place.
We’re building apps for iOS (Swift), Android (Kotlin), and web (React). Our backend is written in Java and runs on Google App Engine and Container Engine.
Do you have experience with iOS, Java server, Android or web development? Like finding simple, elegant solutions to complex problems? Join us, and help blaze a brighter future for social networking! Onsite preferred, but open to remote. Send your LinkedIn, Github, etc., to join@present.co.
Ugh. Android used Harmony because OpenJDK didn't exist yet. As Android's first core library lead, I personally integrated Harmony into Android, and I'm ecstatic to see Android and OpenJDK share the same library code. This will greatly simplify contributing enhancements.
It runs the Jetty web server. When I was the core library lead for the Android platform ('06-'09), we ran Jetty's test suite as part of Android's acceptance tests, so it works great!
Why don't people use phones as servers more often? They're overkill when you can get a Raspberry Pi for ~$50. You typically don't need an LCD, touch screen, accelerometer, cell radio, etc. for a home server.
Also, Android runs a heavily stripped down version of Linux, so running off-the-shelf server software can be tricky.
But you can get a low-spec Jelly Bean phone for $20, with charger, wifi, bluetooth, camera, and battery. I love my Raspberry Pi's (and PogoPlugs) but cheap Android phones are pretty attractive devices too, especially ones that can be rooted without much trouble.
IANAL, so take this with a grain of salt. Did they specifically use the term "IP?" Patents are IP, but IP is not necessarily patents. They could be talking about copyright, and possibly even trademarks. For copyright, if you wrote the code from scratch, you own the copyright, and you aren't infringing copyrighted IP. For 3rd party code that you reuse, you'd just need to demonstrate that you comply with the respective licenses.
Like chris_dcosta said, the best course of action is to ask for clarification. You might ask what exactly they'd like to see proven and how others typically go about proving the same (i.e. ask for examples).
In the apps I've written, it's not common for timer and/or I/O events to come into the run loop during an animation. Hardware acceleration will make a much bigger difference. Romain measured a 1000X performance improvement in one case: http://atnan.com/blog/2011/11/10/ios-vs-android-ics-hardware...
I/O in the main thread and GC are also common culprits. StrictMode is helping with the first. The latter was improved in Android 2.3 with the concurrent garbage collector. There are still more improvements that can be had there, but like I said, HW acceleration is the biggest win. When apps start optimizing for HW acceleration, allocations will likely decrease (because the apps won't be re-drawing on every frame), and GC overhead will become even less of an issue.
Hardware acceleration is a huge boost, but the main remaining problem with Android is stutter. This is where run loops really help.
As you say, I/O in the main thread and GC are central causes. Both are problems that Apple doesn't have, because of run loops and manual memory management respectively.
Also, the focus on multithreading the heck out of everything is not the way to go. There is real, substantial overhead to having multiple threads. Run loops are such a powerful tool precisely because they let you keep everything on the main thread (avoiding context switch overhead) while giving you an easy way to prioritize UI when needed (event tracking mode).
We’re building Present, an innovative social network just for women!
We’d like to hire experienced iOS and Java server engineers. Our iOS app is written in Swift. For the server role, experience with our chosen technologies is a plus: App Engine (Java), Guice, Guava, Objectify, Protocol Buffers, Docker.
Our team is almost 80% women and has experience at Square (former CTO), Google, and Facebook: https://present.co/join.html
Send your LinkedIn and/or GitHub to hello@present.co. Let’s be Present!