[Samsung Unlock Swift 1.0.0.4 - Free Download
Saija Grzegorek
I need to create a remote control app in ios for samsung tvs. I did google too but i can not able to get exact solution. I have seen this SDK link -libraries/smart-view-sdk/sender-apps/ios-sender-appBut is it still allowing me to connect latest tv models also ?
I have also seen that there is TIZEN platform to do it but i am not aware with that also.I am still confused that is its control code need to write in swift or objective c or it will be done via web APIS? because i have seen node.js reference as well for this.
I prefer to use websockets and it is actually quite easy. By looking at the websockets section in this project you will get an idea of how to use websockets to connect to samsung TV and control it by sending commands.
After working for about 2 years on an iOS app using swift, my team and i is considering starting the development of the android version.
I had hopes in the "swift world domination" goal, but it seems that it's not there yet. So here's my question :
What are the various options people are actually using / recommanding today for porting an iOS app to android ?
Try to compile it to ARM, and try to have the binary run over existing libraries / framework that exist on android. I have no idea how big of a task it is (how much of foundation actually runs on android ? i don't even know)
Redevelop it using a cross platform tool (such as kotlin multiplatform, or go with gomobile), reusing the design, and use that version for android. The long term goal being to stop developing the core in swift at all.
Redevelop it using a language that really is aimed at maximum portability from the start, either because it's its goal (rust), or because it compiles to C, which runs everywhere (such as nim or haxe).
Premature optimisation of code reuse is evil. When in Rome do as Romans do. I'd recommend the last option of your list, i.e. Redevelop in Kotlin. And do it in Jetpack Compose (regardless of whether you use SwiftUI or not - if not that would be another carrot to do so). That's the only way to get a true first class platform experience (hopefully that's what you want). Just imagine this situation in reverse, if you had an app for Android and wanted to do a Swift app - how would you feel about any options on that list other than the last one? Sharing design patterns is fine, just don't overdo it, same reasons.
Actually, the reverse scenario would mean that i would have developped my app in kotlin already, so Kotlin Multiplatform would absolutely be my first choice.
Once again, i'm not talking about UI, just the data part.
They announced it in 2018, and the toolchain appears to be maintained (last commit was August, which brought it up to Swift 5.4, and they have PRs from just a few days ago), so it appears they've been using it for a long time. They also have some sample applications, which should help get you started.
From the little documentation that exists about running Swift on Android, it seems like it's going to be a lot of work to run Swift on Android. If you do pull that off and publish to the Google Play Store, that would be amazing!
Cross-platform-ability is overrated, don't do that (including tools like Flutter or Kotlin Multiplatform or Qt or whatever else). You will waste more time overall than you think you will save by code reuse. Been there, seen that. And that's IMHO of course.
I had a look on that project some time ago and hoped that their work would be integrated into the official swift project since.
I'll definite look it up, but i must say using two different swift toolchain (one for ios, another for android) seems like a recipe for disaster..
I'm not sure why you'd think that; they of course are both versions of the open-source compiler with some patches applied (Apple does not maintain 2 entirely separate compilers, nor did Readdle build their own entirely separate compiler). And it at least appears not have been a disaster for them, else they would not be maintaining it 3.5 years later.
And as for cross-platform code? It certainly does exist. No doubt the web browser you're using to view this very page has excellent support for multiple platforms (and very few pieces of software are as complex or as critical as a modern web browser). The notion that you need to rewrite everything "just because" is one I don't think is supported by the evidence.
While FoundationNetworking and FoundationXML are theoretically operable, many SDKs do not include them, due to their dependency on libraries that are part of Android, but not part of its API. Using them is more complicated because bundling the dependencies risks double loading issues, but using the system ones risks version mismatches.
Thanks a LOT for your comment. I'll definitely have a look at your setup. Are you able to tell a bit more about your use case ? what kind of swift library package do you work with on Android ? How large, what's the business context, what kind of OS feature do they access, etc..
I'm really looking for as much information as i can before i go down this road. I'm ready to explore and try bleeding edge stuffs, but it is a commercial project so i can't afford to take too much risk. Knowing that it is a proven viable option at least for some use cases would be reassuring.
It's not "rewrite it just because". I am talking from personal sometimes painful experience of working on 2 [Android + iOS] crossplatform projects and 2-3 other crossplatform projects that didn't involve android. In all those cases the costs we paid for crossplatform-ability over the years (maintainability, debugging, troubleshooting, cost of hiring personnel with relevant skills or repurposing existing personnel, extra communication overhead between teams, etc, etc) drafted the costs of native solutions that we finally were settling upon afterwards. The extra peculiarity on Android was NDK/JNI which I would rather stay away from whenever possible. YMMV.
What you're describing is a scenario that i've always been worried about as well. That's why i'm also wondering about the "code translation" part (using gryphon or other), where obviously platform neutral code could be "shared" (with swift being the reference implementation), while always keeping a "native-looking" kotlin codebase.
Looking at gryphon, my concern is that it uses custom collection classes to prevent side-effects between swift value-based collection vs jvm reference-based collections. It would make the code pretty awkward. But other than that the language are so similar that i really feel it could be a viable approach.
I don't know which of your five options is best- probably depends on your app and what APIs you need to exercise- but it would be easy to try the first option of cross-compiling for Android with my SDK that @SDGGiesbrecht mentioned. I have instructions on building and testing your Swift packages for Android with the official package manager, and a CI on github Actions that you can look at for concrete examples.
I worked in cross-platform development during the end of the Unix wars and the peak of the Microsoft monopoly. Scientific Visualization was a specialization I had. At the time, certain engineering niches needed higher liability and Windows was too unstable, but all the Unix vendors are dying. Then a solution came with Mac OS X, which promised as real Unix combined with a good GUI. Eventually, my work shifted from porting to Mac to embracing Cocoa to create first class UIS deeply integrated with OpenGL visualization systems.
I worked on some commercial game engines. I was the chief architect of the Corona SDK, which allowed people to write native cross-platform games in Lua. I later co-founded Lanica to build a game engine for accelerator people could write native cross-platform games in JavaScript. Since Android development has many problems, I inadvertently became an Android expert out of necessity.
Ouroboros is an ancient symbol of a serpent or a dragon eating itself. It represents an infinite cycle or something constantly recreating itself. With this talk, I hope to give you much more than a checklist of things to do. I want you to see the fundamental concepts that allow everything to work. Nothing here is new. We are reapplying old concepts in slightly different ways, when we talk about the Swift Compiler in native code, think about C compilers in native code. When we talk about Android, think about Unix and Linux. Seeing these analogies may help you understand how everything works.
The most important fundamental that keeps reappearing in this talk is C. C makes everything possible. C is like the building block for everything else because it has special properties. C is the most portable language. Every platform has a C compiler, even the web has a C compiler now. The C ABI is stable and everything is built on top of it. Almost all languages have a way to talk to C. Swift in particular, has one of the best. There is software written in C, which all the other languages can use because they all know how to talk to C.
Finally, consider a native cross-platform game that goes to a whole bunch of platforms beyond Apple and Android written in Swift. SDL provides us all the functionality we need. SDL even provides audio, but for symmetry, I decided to include OpenAL for 3D Audio.
In a prior project, I wrote a program to run a JavaScript performance to suite called Test262, which goes through 11,000-plus files. I use strlcpy in a hotspot. For a hot loop that should have taken 14 milliseconds, it took 9,000 milliseconds.
On the SDK side, I was trying to get my list of 11,000 files inside a directory in the APK. Little did I know, I walked right into a well-known Android performance bug. Pessimistically, this should take no more than a few seconds. Three hours later, I gave up and killed the process.
Android has wonky behavioral rules for dynamic libraries. I wish I had time to cover this in detail because things are affected by this. It is a common source of breakage and often leads to needing to specially modify cross-platform code.
795a8134c1