Three words: cross-platform compatibility.
If you write your game to target specific platforms, you will have to write it ...
It's not just that people might be able to hack into your front-end app. They might be connecting directly to your server with an app that they wrote themselves.
I can get around whatever security in iOS prevents me from modifying an iPhone app, by just using Xcode to write a Mac app that connects to your server, pretends that it is a client app, and asks ...
Yes of course.
Now applications can also be signed, which allows the operating system to tell if an app has been ...
You need a single source of truth. Having a single source of truth that is always available is very handy.
It really makes life easier if you use an always available database as single source of truth and use the server to update the database. The network is not always available. A fast network is not always available. And lots of people do not have ...
Now there is no need to write code twice.
you can use language which provide cross-platform compatibility.
you can use Flutter ,Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase.
you can use Unity for game development.Unity is used to create both 2 and 3-dimensional ...
In ye olden times yes, you would write the game logic twice.
But in the modern era there is no need to write the game logic twice as instead you would target your game logic against a third party game engine such as Unity or Unreal Engine which has already been ported to your favorite mobile platform. In that way you hire people with your preferred game ...
The general principle to follow is to rely on the User Interface surface (UI) only for data input, and to push as much functionality as possible out of the UI into non-UI classes so that they can be automation-tested independently of the UI.
Architectural patterns such as MVC and MVVM facilitate this process by providing a sensible structural framework to ...
The old client version can’t handle weather data. Therefore it mustn’t even try, whatever the server says. So If you want most of the code present but not operational, your client itself must contain a feature flag, set at compile time.
The client displays weather data if the client feature flag allows it (changed at compile time) in a newer version, AND ...
No it doesn't. A social media page, maybe, but even there that's not true. How often do users change their friends/following lists? Much less often I'd wager. What about the list of credit card types, VISA, MC, AmEx, which an online store (like Amazon) accepts? Do you think the cards accepted are changing daily? And its not just the card type, b/c each ...
Part of the reason for this, I think, is that all mobile devices ...
Immutability is a principle in more than OOP.
Isolation is a principle in more than OOP.
Reaching out and touching whatever you feel like is a bad idea for the same reason pouring glue over the gears of a clock is a bad idea. Sure it holds the clock together but that only works well now. Eventually you want things to be able to move.
The only way to know if the user blinked is to capture an image then analyze it.1
You'll probably have a loop
capture an image
if user is blinking
do something with image
According to Wikipedia, people blink every 2 - 10 seconds (or less, when reading) and ...
Instead of a flag, the backend could return an app version that the client must have in order to use the feature. Example: "show-weather":">=2.0.0" could be used to indicate that clients starting with version 2.0.0 may use the feature.
The existence proof is that I (and at least a few other developers I know of) have apps in both the iOS and Mac App stores which have been built from a single Xcode project and code base, using Catalyst.
Some simple, single view Swift+storyboard iOS apps just require checking a box, and they might run on macOS as is, even if they also include ...
If your mobile application is advanced enough to handle server errors, then it has a middle layer of its own. The exact same methods you would use within the API's middle layer is perfectly acceptable here in this middle layer.
I'm interpreting middle layer to mean Business Layer.
The question is why you need an incomplete feature behind a run time feature flag.
As long as you are developing a larger feature which is not production-ready, you want to disable it completely in "production", and only enable it only in you local development environment. And that is a scenario where compile time feature flags are better suited for, ...