Delphi users on Android mobile development
Valentine, you showed your first application in Delphi for Android . Does it solve a specific task or is it just an initiative development, “first attempt at writing”? Are real business needs behind this?
The first mobile application written in Delphi for Android was for me a kind of test stone in the direction of the possibility of developing certain parts of the information structure of the enterprise on mobile platforms.
In many enterprises (which are our clients), you can immediately find tasks that can be carried out on a mobile platform. These are, first of all, tasks related to personnel, who do not have access to information system information from a regular computer or laptop, no local network and WiFi, only a mobile network. These are employees of remote sites where it is not possible to organize a stationary workplace due to certain specific features, for example, couriers or managers on the road.
For such tasks, an Android tablet with a 3G module is a good solution. We are required to provide a connection to the database, a convenient interface, compact data exchange traffic.
')
As for the tasks to be solved, I can describe the tasks that we are solving now, using mobile development for Android briefly, but without specifics (respecting the interests of our clients).
One of the tasks: there is a specialist located at a remote site who has to transmit a small amount of operational information about the order - the current state of the problem that he solves and some output data. The data must be transmitted to the information system promptly, since the further passage of the order through the chain depends on it. In addition, to solve his problems, he should receive additional relevant information that is entered into the system by other specialists, possibly also from a mobile device. Using a mobile device, and not a PC under Windows, is mainly determined by the weight characteristics of the tablet. "7 inches" easily fit in a large pocket or small handbag and are not felt by the person as additional weight, which allows you to carry these devices always and everywhere. Yes, and they can work more than 6 hours.
How problems were solved before: either the specialist carried a laptop with him with the ability to connect to the 3G network, or he called or sent an SMS to the dispatcher. Working with a laptop is not always possible, and work through the dispatcher is a loss of speed and relevance of data and, of course, the human factor.
Carrying out such a task on a mobile platform in the version - MS SQL Server DB (only it is for our tasks) - Data Snap - Android application is devoid of the above disadvantages.
Another typical task that is very much in demand is the collection of operational data from remote sites that do not have, and there will be no possibility of deploying stationary workplaces, due to certain features — for example, an unguarded, unheated room without electricity (it happens sometimes).
For such a task, an inexpensive tablet on Android is a very suitable solution, even the running time is not very critical, since only a session connection to the database is required.
In our production tasks, solutions for iOS, alas, remain on the sidelines, due to Apple’s policy of updating applications, and I’m not even talking about the cost of devices, and in the near future no changes are expected for the better. For mass use, for example, in manufacturing, the cost of ownership and the update rate of specialized software is essential, for example, when deploying 100 or more mobile workstations.
There is also the task of online data entry from points distributed throughout the enterprise, where the employee has a workplace with a stationary computer connected to the network, but again, due to the specifics of the work, he must enter some data away from the workplace, for example, check the order bundle. The order collector must see the order items, and he enters only “OK” or “Problem”. For such tasks, the use of a Wi-Fi network and an Android tablet with a Wi-Fi module makes the cost of the solution even lower.
The basis for designing a mobile application is to lay a kind of “use case”. Can you share?
When developing the interface and the ideology of the mobile application, both the features of the mobile device itself - touch input, the estimated screen resolution, and the “features” of the user are taken into account. In other words, the same functionality implemented for the manager on the road and for the operator at the remote site may differ due to the “perception peculiarities” of the user of the mobile device.
First of all, it is the comfort of work without compromising the functionality of the application. Users of our client-server applications are used to working with a functionally saturated screen, in fact, a remote control, in which all the necessary information is always at hand, or in sight, either available in one click, or delivered by pop-up notifications. Therefore, for the interface of a mobile application, it is very important that when working, the user does not feel constrained in his actions and access to the necessary information.
The apotheosis of the user's discomfort is very well expressed by the phrase “You are forcing me to move the mouse!” Therefore, ideally, we would like the user of a mobile application to perceive him almost as a game, or at least he was pleased to work with him.
And suddenly, when developing, it turns out that using “grids” to display information on mobile devices is not always justified - they are inconvenient in scrolling, and in most cases using ListBox and ListView provides much more intuitive features to users of mobile devices.
The most annoying thing is that in the mobile version of the application, the user loses the desktop “multiwindow”, and here you have to decide what information you have to sacrifice in general to mobilize ’the solution, and which to hide under bookmarks or put into separate forms or pop-up menus. Therefore, the interfaces of the “desktop” task and its “mobile brother”, with similar functionality, are completely different.
Since the mobile application is developed for a specific customer and task, there are no problems with compatibility with devices, since we know exactly which devices and with which characteristics the customer will use.
You can ask for a few screen shots - preferably in the course of script development?
There are no technical problems, but there are other considerations. Our clients regard the presence of mobile solutions in their assets as an additional competitive advantage, so they decided to give up putting pictures on them. By the way, this is a big problem not only for mobile applications, but for client-server systems. I can only show the most pilot project, and even then I had to “gloss over” it. The interface of the full-scale current project would have to smear the whole, sorry, "by the ears", only the "charging strip" would remain. Without damage to customers, I can show only the very first prototype, and even then - with blurred data. There will also be a project view in the IDE for the thin mobile client and DataSnap server.
Working through the application interface turned out to be quite a laborious task precisely in terms of ergonomics, while the actual functionality of the application did not deliver any problems, while working in the familiar programming environment, Delphi XE5.
By the way, like most developers, I “sculpt” something for myself. This can show:
What is the component basis of the application? What is it used for?
In developing our applications, we always try to minimize the set of third-party components, to the extent possible, to have the least possible dependence on other developers when translating projects to new versions of Embarcadero products, especially since they come out with such frequency.
In the case of the development of our mobile applications, even the standard set of components included in the Delphi XE5 Enterprise version is still enough, since there is the possibility of mobile development, Data Snap and FireDAC.
In addition, the use of "styles" for Android is quite capable of reviving the application interface.
Externally and functionally attractive is the solution that TMS offers, but so far I have used these components only in developing applications for Mac OS. It would be great if Embarcadero included them in the standard distribution, at least from the Enterprise version. After all, the same thing happened with Fast Report and Fire DAC.
How and where do the data come from?
Working with data is organized as follows - there is a database server (MS SQL Server), there is a Data Snap server, through it the client on Android works with data.
How are user actions recorded in the “database” (if there is a connection with it)?
Naturally, there is a connection with the database; everything that the user contributes is immediately reflected in the database.
How did the managers manage without this application?
Naturally, both managers and employees at remote sites used to do without mobile applications. Before, even ordinary people did without mobile mail and a telephone. They used laptops, called, wrote letters, sent couriers with packages, prepared reports with such a time lag that the data were already irrelevant.
How do you think business processes have accelerated?
Generally speaking, when automating production, the use of mobile solutions (here I mean not only mobile applications, but also web solutions) increases production efficiency so significantly that it results in fairly solid figures. Because there are processes that are technically not implemented at all in the immobile version, or they are implemented very costly.
The main advantage that a mobile solution gives is an operational interaction with feedback, this is exactly what is the basis of client-server solutions - all processes occur in real time.
Do you see further development of the application functionality?
Yes, at least for the mobile manager there are already ideas for development, and these ideas are already coming not only from us, but also from the users themselves. You can develop endlessly, with time and funding available, you can bring the functionality to the "desktop" system, there are no special technical problems - Embarcadero Delphi XE5 Enterprise allows it. If the system was originally designed as a three-tier, then the translation speed is determined by the technical speed of writing code. The main thing - do not rush and solve problems in stages.
The main problem is the size of the screen of the mobile device and ergonomics (the size of the control element must be substantially larger for a finger than for a mouse).
How do you think this decision is typical in the framework of "corporate mobility"?
I believe that our mobile solutions are typical for those industries for which we have developed them, since the main business processes for different customers in one industry often differ only in the preferences of managers and historically established rules (even taking into account geographical location).
For example, users of our mobile solutions are a sales manager, warehouse worker, forwarding driver, order picker, remote site logistics, purchase / sales manager, raw / product master, document approver, equipment repairman (yes, our systems monitor equipment), production technologist. That is, typical production problems are solved.
Take this opportunity to provide us with "sugar-free" wishes for the company Embarcadero
I think that in this matter I will not be original, but unlike other “stone-throwers” I will try to throw them smaller, understanding those complex and new tasks that solve the products of the line of development tools. By the way, at the same time I consider the development of mobile applications on other (I will not name here what) development tools, so I can compare two worlds - two systems, and make some suggestions
Everything described above does not hinder much of the development process, but solving these problems would significantly increase the attractiveness of Embarcadero as a means of developing competitive mobile applications not only in the corporate sector.
Thank you, Valentine!
The first mobile application written in Delphi for Android was for me a kind of test stone in the direction of the possibility of developing certain parts of the information structure of the enterprise on mobile platforms.
In many enterprises (which are our clients), you can immediately find tasks that can be carried out on a mobile platform. These are, first of all, tasks related to personnel, who do not have access to information system information from a regular computer or laptop, no local network and WiFi, only a mobile network. These are employees of remote sites where it is not possible to organize a stationary workplace due to certain specific features, for example, couriers or managers on the road.
For such tasks, an Android tablet with a 3G module is a good solution. We are required to provide a connection to the database, a convenient interface, compact data exchange traffic.
')
As for the tasks to be solved, I can describe the tasks that we are solving now, using mobile development for Android briefly, but without specifics (respecting the interests of our clients).
One of the tasks: there is a specialist located at a remote site who has to transmit a small amount of operational information about the order - the current state of the problem that he solves and some output data. The data must be transmitted to the information system promptly, since the further passage of the order through the chain depends on it. In addition, to solve his problems, he should receive additional relevant information that is entered into the system by other specialists, possibly also from a mobile device. Using a mobile device, and not a PC under Windows, is mainly determined by the weight characteristics of the tablet. "7 inches" easily fit in a large pocket or small handbag and are not felt by the person as additional weight, which allows you to carry these devices always and everywhere. Yes, and they can work more than 6 hours.
How problems were solved before: either the specialist carried a laptop with him with the ability to connect to the 3G network, or he called or sent an SMS to the dispatcher. Working with a laptop is not always possible, and work through the dispatcher is a loss of speed and relevance of data and, of course, the human factor.
Carrying out such a task on a mobile platform in the version - MS SQL Server DB (only it is for our tasks) - Data Snap - Android application is devoid of the above disadvantages.
Another typical task that is very much in demand is the collection of operational data from remote sites that do not have, and there will be no possibility of deploying stationary workplaces, due to certain features — for example, an unguarded, unheated room without electricity (it happens sometimes).
For such a task, an inexpensive tablet on Android is a very suitable solution, even the running time is not very critical, since only a session connection to the database is required.
In our production tasks, solutions for iOS, alas, remain on the sidelines, due to Apple’s policy of updating applications, and I’m not even talking about the cost of devices, and in the near future no changes are expected for the better. For mass use, for example, in manufacturing, the cost of ownership and the update rate of specialized software is essential, for example, when deploying 100 or more mobile workstations.
There is also the task of online data entry from points distributed throughout the enterprise, where the employee has a workplace with a stationary computer connected to the network, but again, due to the specifics of the work, he must enter some data away from the workplace, for example, check the order bundle. The order collector must see the order items, and he enters only “OK” or “Problem”. For such tasks, the use of a Wi-Fi network and an Android tablet with a Wi-Fi module makes the cost of the solution even lower.
The basis for designing a mobile application is to lay a kind of “use case”. Can you share?
When developing the interface and the ideology of the mobile application, both the features of the mobile device itself - touch input, the estimated screen resolution, and the “features” of the user are taken into account. In other words, the same functionality implemented for the manager on the road and for the operator at the remote site may differ due to the “perception peculiarities” of the user of the mobile device.
First of all, it is the comfort of work without compromising the functionality of the application. Users of our client-server applications are used to working with a functionally saturated screen, in fact, a remote control, in which all the necessary information is always at hand, or in sight, either available in one click, or delivered by pop-up notifications. Therefore, for the interface of a mobile application, it is very important that when working, the user does not feel constrained in his actions and access to the necessary information.
The apotheosis of the user's discomfort is very well expressed by the phrase “You are forcing me to move the mouse!” Therefore, ideally, we would like the user of a mobile application to perceive him almost as a game, or at least he was pleased to work with him.
And suddenly, when developing, it turns out that using “grids” to display information on mobile devices is not always justified - they are inconvenient in scrolling, and in most cases using ListBox and ListView provides much more intuitive features to users of mobile devices.
The most annoying thing is that in the mobile version of the application, the user loses the desktop “multiwindow”, and here you have to decide what information you have to sacrifice in general to mobilize ’the solution, and which to hide under bookmarks or put into separate forms or pop-up menus. Therefore, the interfaces of the “desktop” task and its “mobile brother”, with similar functionality, are completely different.
Since the mobile application is developed for a specific customer and task, there are no problems with compatibility with devices, since we know exactly which devices and with which characteristics the customer will use.
You can ask for a few screen shots - preferably in the course of script development?
There are no technical problems, but there are other considerations. Our clients regard the presence of mobile solutions in their assets as an additional competitive advantage, so they decided to give up putting pictures on them. By the way, this is a big problem not only for mobile applications, but for client-server systems. I can only show the most pilot project, and even then I had to “gloss over” it. The interface of the full-scale current project would have to smear the whole, sorry, "by the ears", only the "charging strip" would remain. Without damage to customers, I can show only the very first prototype, and even then - with blurred data. There will also be a project view in the IDE for the thin mobile client and DataSnap server.
Working through the application interface turned out to be quite a laborious task precisely in terms of ergonomics, while the actual functionality of the application did not deliver any problems, while working in the familiar programming environment, Delphi XE5.
By the way, like most developers, I “sculpt” something for myself. This can show:
What is the component basis of the application? What is it used for?
In developing our applications, we always try to minimize the set of third-party components, to the extent possible, to have the least possible dependence on other developers when translating projects to new versions of Embarcadero products, especially since they come out with such frequency.
In the case of the development of our mobile applications, even the standard set of components included in the Delphi XE5 Enterprise version is still enough, since there is the possibility of mobile development, Data Snap and FireDAC.
In addition, the use of "styles" for Android is quite capable of reviving the application interface.
Externally and functionally attractive is the solution that TMS offers, but so far I have used these components only in developing applications for Mac OS. It would be great if Embarcadero included them in the standard distribution, at least from the Enterprise version. After all, the same thing happened with Fast Report and Fire DAC.
How and where do the data come from?
Working with data is organized as follows - there is a database server (MS SQL Server), there is a Data Snap server, through it the client on Android works with data.
How are user actions recorded in the “database” (if there is a connection with it)?
Naturally, there is a connection with the database; everything that the user contributes is immediately reflected in the database.
How did the managers manage without this application?
Naturally, both managers and employees at remote sites used to do without mobile applications. Before, even ordinary people did without mobile mail and a telephone. They used laptops, called, wrote letters, sent couriers with packages, prepared reports with such a time lag that the data were already irrelevant.
How do you think business processes have accelerated?
Generally speaking, when automating production, the use of mobile solutions (here I mean not only mobile applications, but also web solutions) increases production efficiency so significantly that it results in fairly solid figures. Because there are processes that are technically not implemented at all in the immobile version, or they are implemented very costly.
The main advantage that a mobile solution gives is an operational interaction with feedback, this is exactly what is the basis of client-server solutions - all processes occur in real time.
Do you see further development of the application functionality?
Yes, at least for the mobile manager there are already ideas for development, and these ideas are already coming not only from us, but also from the users themselves. You can develop endlessly, with time and funding available, you can bring the functionality to the "desktop" system, there are no special technical problems - Embarcadero Delphi XE5 Enterprise allows it. If the system was originally designed as a three-tier, then the translation speed is determined by the technical speed of writing code. The main thing - do not rush and solve problems in stages.
The main problem is the size of the screen of the mobile device and ergonomics (the size of the control element must be substantially larger for a finger than for a mouse).
How do you think this decision is typical in the framework of "corporate mobility"?
I believe that our mobile solutions are typical for those industries for which we have developed them, since the main business processes for different customers in one industry often differ only in the preferences of managers and historically established rules (even taking into account geographical location).
For example, users of our mobile solutions are a sales manager, warehouse worker, forwarding driver, order picker, remote site logistics, purchase / sales manager, raw / product master, document approver, equipment repairman (yes, our systems monitor equipment), production technologist. That is, typical production problems are solved.
Take this opportunity to provide us with "sugar-free" wishes for the company Embarcadero
I think that in this matter I will not be original, but unlike other “stone-throwers” I will try to throw them smaller, understanding those complex and new tasks that solve the products of the line of development tools. By the way, at the same time I consider the development of mobile applications on other (I will not name here what) development tools, so I can compare two worlds - two systems, and make some suggestions
- I know that for corporate mobile applications its size is not critical, especially since installing a new version on a tablet by a user is easy. However, I would still like to see a smaller amount of applications.
- I understand that this is the normal desire of the application - to occupy all the RAM when working. Live Binding's appetites are especially good - I would like some progress here too.
- An unpleasant feature of the "inhibition" of the interface is noticed when using Live Binding, as when working with a terminal server over a bad channel. I want to accelerate.
- When I start the application ... I don’t have time to drink coffee, but I can make it in time)) 5-7 seconds is the minimum.
Everything described above does not hinder much of the development process, but solving these problems would significantly increase the attractiveness of Embarcadero as a means of developing competitive mobile applications not only in the corporate sector.
Thank you, Valentine!
Source: https://habr.com/ru/post/205380/
All Articles