Re: Samsung Unlock Swift 1.0.0.4 - Free Download
Rivka Licklider
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.
Now that these changes are ready, we will be starting to explore how to let Java/Kotlin use Swift APIs. We would like to have a level of interoperability that lets Java/Kotlin invoke a subset of Swift APIs in an effective and ergonomic manner. Please let us know if you have ideas for how such interoperability should look like and/or work!
We would like to see Swift for Android succeed, and we think that as part of that Android should start to move in the direction of being a supported platform that Swift can target. More specifically, it would be great if there was a way to set up a pre-commit CI for Android, in addition to currently existing post-commit CI ( -external.swift.org/). What do other community members think of that idea?
Yes please! This would be absolutely wonderful.
I'm all for Android being a supported platform. It deserves some resources and would strengthen Swift as a language choice similar to how Windows did.
This would require some small changes to the few current Android users' packages, but is the right move for the future. Pinging @drodriguez, @Geordie_J, @mstokercricut, and @johnburkey, as they've all tried building for Android in the past. Let us know if you are okay with making this change with Swift 6.
it would be great if there was a way to set up a pre-commit CI for Android, in addition to currently existing post-commit CI ( -external.swift.org/). What do other community members think of that idea?
That would be great. I discussed moving Android from the community CI to the official CI, but keeping it post-commit, with some members of the core team last November. They OK'ed the move, but I've since been bogged down with some non-tech work at home since December and have done nothing for that move to the official CI, using my lessened time for smaller items like upstreaming the nullability annotation changes for NDK 26.
I built a swift 5.8 GitHub Action change using a lot of @Finagolfin 's excellent work for examples, and added it to alamofire for android. I need to update my tool chains since it's been a bit but I would love to do this with newer tool chains.
I've built entire apps for android with swift doing rendering and business logic with minimal interoperability surfaced up to the JVM side. I plan to continue doing that once my need for android arises again. I know it's possible and a joy once you get it working well.
I think improving the state of the post-commit CI is the right first step, so it's great to hear you're already working on it! I don't have much insight into setting up a pre-commit CI yet, but I'll do some digging into the current post-commit CI setup to understand it better before we propose a concrete action plan for pre-commit CI.
I don't have much insight into setting up a pre-commit CI yet, but I'll do some digging into the current post-commit CI setup to understand it better before we propose a concrete action plan for pre-commit CI.
The current post-commit community CI simply compiles the Android stdlib on linux and then runs the compiler validation suite in host test mode, ie skipping the 1k executable tests that would need to run on Android.
It has been broken for more than a month because it doesn't have a prebuilt Swift toolchain installed, and Swift trunk is currently broken when bootstrapping on linux, pretty much requiring a prebuilt host toolchain at this point.
I plan to get that running on the official CI by installing a prebuilt Swift toolchain for linux, then expanding it to run the executable tests in the Android emulator, before getting it to cross-compile the corelibs like libdispatch and foundation for Android also, the last of which my daily Android CI has been doing for years.
Good point! We don't need it in Swift 6 ourselves, but it sounds like the community would benefit from this change being in Swift 6. It does make sense to switch from Glibc to the Android module now in Swift 6, since it will be a major release, and thus anyone who depends on Glibc for Android now will know that there's a clear boundary that denotes when the Android module is introduced.
People have been building it on macOS for a long time, but the official doc instructions I linked a couple weeks ago have only been validated on linux. If you want to try them on macOS, I recommend using the Homebrew OSS toolchain.
We would like to see Swift for Android succeed, and we think that as part of that Android should start to move in the direction of being a supported platform that Swift can target. More specifically, it would be great if there was a way to set up a pre-commit CI for Android, in addition to currently existing post-commit CI ( -external.swift.org/ ). What do other community members think of that idea?
We've been working with the excellent toolchain from @Finagolfin for a little while now to build several large-ish Swift libraries for Android (in addition to Windows, Linux, macOS) and integrating them with Kotlin projects. We read the Swift code, identify types, generate analogous Kotlin type interfaces, and generate code that uses the JNI to hook the Kotlin types to the Swift types. We then package all that up and use Maven for distribution of the libraries. It has worked great for us, but is currently closed source. I'm super excited to see work on a similar system that is open source!
I completely agree that supporting Android as a supported platform that Swift can target will strengthen Swift as a language choice as @STREGA suggests. Even if Kotlin Swift interop is not part of the initial support, being able to call interfaces exposed using @_cdecl using the JNI & NDK would be a huge boon.
Much of the pushback I've gotten about using Swift as the language choice for shared code is the lack of official Android support on Swift.org - Platform Support. Getting the OS on the officially supported list would quiet much of that opposition, giving confidence that Android support won't just disappear in future Swift versions. I bet many other organizations have had similar conversations and decided against Swift for that reason.
I am currently porting the 6.1 trunk portion of my daily Android CI to this new Android overlay, you can get an idea of the "small changes" I mentioned before from that patch. Once @Alex_L's pulls are in, my CI will automatically produce a 6.1 trunk Android SDK that you can use with an official 6.1 trunk snapshot toolchain, hopefully on Windows too, to port your own packages and make sure everything is still working fine with this new Android overlay.
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.
b1e95dc632