The theme of native engines simplifying the work with 3D graphics for Android is the headache of many developers. While there is SceneKit for iOS, Android developers were forced to either refer to cross-platform solutions (Unity3d, LibGDX, etc.) or use own/open source solutions with limited functionality. The appearance of Sceneform SDK solves not only this problem but also encapsulates the work with ArCore SDK, allowing developers to natively implement AR solutions without using the third-party SDK.
The report will consider the practicability and limitations of Sceneform SDK in regard to augmented reality (AR) projects. Such themes as SLAM, ArCore SDK, recognition and tracking of image-based markers, Cloud Anchors and alternatives existing on the market will also be considered.
About speakerCTO in ROAR Augmented Reality Platform, since 2009 in mobile development. Main work lines: development and mentoring on development for Android, Augmented Reality, Computer Vision, Machine Learning, IoT.
If you want to share the code between Android and iOS but you don't feel like doing C++/JNI, React Native, Flutter,
Eternal choice: quick, cheap or beautiful. Until recently, it was possible to get two of three, while developing mobile apps. Most often UX/UI was sacrificed, and the situation was especially bad in the category of business apps. The users were offered something that at best did not break HIG platform, and often it was totally a tracing of web versions. But with Flutter the situation changes!
In this report we will talk about how to write reliable, beautiful apps, at ultra-speed and at no cost.
About speakerI've been writing the code for a price since 2006, in mobile development since Retina has just appeared, android has made us sad, and Windows Phone was cool, that is already 7 years. I hold the position of Head of Mobile Unit at Ciklum. In my spare time I learn something new and also teach others.
Now, it is not enough just to write the code, it should be written beautifully and "correctly". Since these concepts differ greatly from person to person, at some point the teams come to formalization of beauty and correctness. Some teams, being tired of swearing in the pull requests by reason of the bad code, go further and set up the automatic checks. Someone even trusts the tools so much that allow them to modify and correct the code.
In this report, I'll talk about libraries and tools aiming at work with the code. Let's consider the main distinctions between libraries and field of their use. After the report, you will finally distinguish SourceKit from SourceKitten, libSwiftSyntax from Swift Syntax.
About speakerSoftware Engineer at MacPaw. Many years' experience of iOS development, author of several close-iOS projects that are very popular in narrow circles. I actively participate in Ukrainian conferences as speaker, where I carry the light of knowledge to all those interested, sharing the pieces of my gathered experience. I like to program in time free from programming. Interests: programming, science fiction, quantum computing, data visualization.
A good designer is extremely valuable. He will prepare screens, decide on colour and fonts, and work at the application so that it meets all the requirements of the target platform. But it happens that client's corrections to the finished design (or even a ready-made application) create for developers the amazing opportunities for refactoring exercises, for example:
If you are annoyed by similar situations, then most likely your tool is not good enough. ;)
In this report, we will take several screens from the Mobile UI Inspiration mailing with the most gorgeous design fantasies and implement them on Flutter. Be careful, there will be a lot of code!
About speakerI've been writing the code for a price since 2006, in mobile development since Retina has just appeared, android has made us sad, and Windows Phone was cool, that is already 7 years. I hold the position of Head of Mobile Unit at Ciklum. In my spare time, I learn something new and also teach others.
Using React Native, Flutter, Hybrid Web, Unity, Kotlin Multiplatform could be an interesting strategy, but what if we want to stay within traditional native development on both platforms?
A syntax of Swift and Kotlin looks pretty similar, especially if you are cooking it with RX. So, what if we will implement a new feature on one platform and then, kinda, copy-paste the code to another one, with minimum modification? How good it will work for us? How should we deal with platform-specific features? Will this strategy make a project too complex?
This speech will show the way, how to design your project in order to minimize the headache of implementing the same feature for both mobile platforms. Also, we will talk about gains and losses during implementation on a real project with this design idea.
About speakerSenior Mobile Engineer at Intelity. Max has been working in mobile development for more than 6 years and specializes in multimedia-based projects. He had a chance to work on a few complex projects, video SDK, and a mobile game framework. All of it was designed to be working on iOS/Android/WinPhone. He has been established a course of Mobile development at Faculty of Informatics and Computer Science, Igor Sikorsky KPI. As a hobby, with a help of IoT devices, Max is growing the tiniest tomatoes in the world on his balcony.
My team's main focus in the recent past was rebuilding our company's main Android product - the trading app.
Our app was nearly 500k lines of code worth, written by dozens of devs in a timespan of 8 years, almost fully in Java. This obviously affected our velocity and caused us to deliver slower than we could potentially do.
During my talk, I'd like to go through the challenges we've faced and architecture decisions we have made to end up having a much healthier codebase.
Come to my talk to learn how we:
About speakerI'm working as an Android Technical Team Lead at in IG in Krakow, where he lives. Member of the Google Developer Expert program on Android, also co-organizes GDG Krakow's community meetups. An avid fan of railway transportation and football, father of twins.
Optional is a fundamental type in Swift. While it’s almost everywhere, most developers don’t use it to the full extent or even use it in a wrong way. Such misconceptions lead to code duplication, amiss implementation of design patterns and neglect cool features available in Swift. There's a couple of crucial ideas behind this type that can make your daily Optional routine efficient and safer.
During the talk, we'll discuss how to and why we should avoid optional binding. By refactoring samples from code reviews, we'll learn what's great about functional programming in Swift. We'll also see how Optional affects DI and error handling and what can we do with it.
About speakeriOS Developer at Ciklum Solutions Team. I've been struggling with Xcode and Apple's attitude to developers since 2012. But still, I enjoy the process, try to learn something new and like to share knowledge with others.
Обрати архітектуру для розробки не просто. Серед безлічі можливих архітектурних рішень для Flutter у фаворити вибились BLoC і Redux. BLoC ― нове рішення від компанії Google, яке лише починає набувати популярності. Redux ― незмінний улюбленець ком'юніті. І, звісно, мій. Саме про нього і поговоримо.
Під час доповіді ми візьмемо готовий UI шар і реалізуємо всі необхідні Redux компоненти: Store, State і Reducer Actions. А також специфічні для Flutter елементи ― StoreProvider і StoreConnector.
About speakerSenior Android розробник у SteelKiwi Inc. У мобільний розробці з 2013 року. Після першого публічного релізу Flutter на Google I/O 2017 загорівся крос-платформною розробкою додатків з Flutter. Відтоді я ентузіаст цієї технології. Останніх півроку реалізовую цю технологію у проектах.
|Реєструйся та будь в курсі про нові доповід та анонси подій|