101–110 of 123 posts
I'm leaning towards using [Meteor](https://www.meteor.com/) to share code between mobile apps and web apps.
Using cordova shells is pretty neat for business applications. Would be interested in thoughts.
Earlier quoted context omitted.
What’s the threat of a security vulnerability in a 3rd party mobile app that tightly sandboxes your app - especially for a none financial app? I would think that if even a vulnerable app could affect other running processes or the OS itself, you’ve found a vulnerability in the underlying OS.
Presumably the user of the app cares about their own data...
Earlier quoted context omitted.
How do you propose that an security vulnerability in an iOS app that doesn’t result in a jailbreak will allow someone to copy the app from an iOS device on to another device? Also, are you claiming that using C == “not striving for quality” or that it is not “best practice” to use C? And on a side note, most corporations don’t care about “quality” or “best practice”, they care about shipping and selling software. Two…
Industry is young, but thankfully returning goods on app stores and suing companies for delivering bad software is starting to happen. I am claiming both when using a language whose security reports from Google, Apple, Microsoft, ARM, Linux kernel just increase in size every year with the amount of memory corruption and UB induced security exploits. Like those reports advise, usage of C should be constrained to envir…
Since no one else has said it, I'll be the voice of reason. Share your design specs only, and let each platform team write the implementation in the language that they think best. Yes, you'll have two teams spending time on doing the same thing. However, you'll get important benefits. Each team will be able to implement appropriately for their platform. While iPhones and Android phones are rather similar in terms of…
This is a UI-centric take. There are lots of internals that could/should be shared between apps. Recently relevant examples: a customized WebRTC stack, a websocket client with extra authentication and delivery rules. FWIW, my take on this has been to embrace Conway's law: if you have enough shared work to form a team around it, then break off a c++/whatever library and a team to maintain it. But if the hope is just t…
Dart+flutter?
C++. It is part of both SDKs, you have direct support for mixed mode debugging on the IDEs. No need of extra tooling. On Android JNI is always going to be a pain, but at least with C++ Studio gives you an hand on accessing JNI APIs.
Earlier quoted context omitted.
I love hacker news. This is the comment I came here for. Just use this : A language that is (at best) fringe on the platform you are using. Here's a toolset nobody has ever heard of. Now build your mission critical bit of infrastructure on this house of cards, wait for the toolset maintainers to be outpaced and under-resourced by underlying OS/platform changes and then have to rewrite the whole thing which if it does…
Well, developers are the kind of people that love to be contrarian, so it shouldn't be that surprising. Half the fun (in my mind) is doing something no one else is doing. Being novel. It's probably unwise in a business sense, but if everyone was being wise all the time, there wouldn't be much fun in software development.
Make your core logic in C++ and write bridges for Kotlin and Swift, where only the UI logic is involved. C++ has the better ecosystem so far and the very modern standard (C++17) let you write robust code. There are also so many tools that help you catch errors and typos, plus thousands of libraries available.
Earlier quoted context omitted.
What “risk” is there in an overflow from using strncmp, strncpy, etc? C++ still isn’t as easy to interop with other languages as C and the low level APIs built into operating systems are not going to use C++/STL and you still end up converting to standard C strings and arrays.
strncpy notoriously doesn't necessarily 0-terminate. (It also always pads the full length with zeroes if necessary, so it's almost never what you actually want to do.) The C standard library is full of these footguns. I won't say C++ doesn't have its bad parts, and I certainly wouldn't say that it's impossible to avoid the bad parts of C (some would), but you probably aren't going to manage.
The typical error case with C is something like
char *a = “abcd”; //5 bytes
char *b = “efgh”;
char c[8];
strcpy(c,a);
strcat(c,b); //buffer overflow by 1 byte.
The blog post about how it works https://blog.readdle.com/why-we-use-swift-for-android-db449f... And our toolchain https://github.com/readdle/swift-android-toolchain
The biggest disadvantage is the lack of swift evaluation in Android Studio LLVM debugger. But we work on this.