Posts by Sergey

Open files in external apps from Firemonkey

May 9th, 2018 Posted by Embarcadero, Mobile No Comment yet

It’s rather a common scenario when a Firemonkey mobile app needs to open a file. It might be a PDF document, an image or video. And while opening a file directly inside of Firemonkey app is totally a legit strategy, sometimes it may be not so easy to implement. TImage provides great support for various graphics formats, but what about PDF? Implementing PDF support for multiple platforms may be quite a challenge. Luckily, both iOS and Android provides a shortcut, we can ask OS to open a document in a third-party application of user’s choice.

And beyond that, mobile OS usually provides more options than just “open a file”. We can also share or print a file, which may be useful for users. (more…)

Internet connectivity state management in Firemonkey

April 12th, 2018 Posted by Embarcadero, Mobile 2 comments

It’s a common task for a Firemonkey developer to check Internet connectivity. It might be useful to notify a user that he is going to download a huge amount of data using his mobile connection, or just indicate Online/Offline mode on the UI.

This functionality is missing from RAD Studio classes, so lots of developers out there have made solutions for their needs, although most of them only solve problems of their developer and may not fulfill your needs.

In order to fill that gap I made a solution which follows these guidelines:

  • Android and iOS support
  • ability to retrieve current Internet connectivity state – disconnected, connected to WiFi, connected to mobile data
  • Internet connectivity state listener which fires every time when connectivity changes
  • a cross-platform interface with encapsulated platform-specific solutions

(more…)

TNotifyEvent debouncing in Delphi

August 24th, 2017 Posted by Embarcadero No Comment yet

Every developer who works with UI handles a lot of user input. And it’s not a rare situation that we don’t need to handle every incoming event because there might be just too many of them.

Consider this example, a user fills an email field on “Sign up” form in some application which works with a REST API. We want to validate entered email before a user actually will click “Submit” button. To do it, we make a call to hypothetical “/email/validate” REST endpoint and display validation status on the UI, which enables a user to adjust his input until he finishes working with the form.

Some people type really fast, so we don’t want to make a REST call for every entered character. Lots of APIs have request limits and in order not to exceed them it’s necessary to “throttle” events emitted by fast user typing.

(more…)