hello, Urban!

how can I help you today?

Hey Mark, it's your fellow sub Urban (again) with bunch of questions (same old)

darn -- I was hoping for new and exciting questions! :-)

Thank you for being here today

Hopefully you will find them exciting enough

who-hoo!

Once again sorry to ask you that much but you are one of the best

I try to be useful -- so, what's your first question?

And as I am looking to become one, I am disturbing poor you

First question is about data sync (online database with internal one): I have looked into SyncAdapter which is supposedly optimised for such scenarios. However, I have found it to be (overely) complicated while many ppl report problems when using it. Therefore, my question is if you would recomend synching data using SyncA or should I opt for other forms of data synchronisation?

"overly complicated" is a nice, polite description of SyncAdapter

and so I have avoided it

in addition to the complexity, you do not have any control over the timing of the sync operations, and usually The Boss wants some amount of control

so, I do not think that SyncAdapter is popular

most projects use something else, such as WorkManager

So, how did you usually perform sync operations? Manually or using a special mechanism?

in terms of a trigger for the timing, I would recommend WorkManager

in terms of the actual sync itself, that depends a lot on the local and remote data sources

unless you have a specific environment set up for automatic synchronization (e.g., git, Couchbase Mobile), synchronization is a complex problem

Okay, thank you for that answer

So, doing it manually (such as inserting rows into some table) is an accepted way of doing this?

again, unless you have an environment that handles those details for you (e.g., git, Couchbase Mobile), you have no choice

okay, thank you very much for such detailed answer

Next question is regarding the real-time messages: I know that many people use FCM. Would you suggest using this for message deliveries or should I look into other alternative? Also, is PHP a good back-end for sending messages or should I learn to do it with JavaScrips, such as Node.js?

"Would you suggest using this for message deliveries or should I look into other alternative?" -- well, that depends

FCM is only available on Google Play devices

if you are distributing to other devices, such as to users in China, you will need at least to have some alternative that will work for those users

on the other hand, due to Android's power restrictions, creating an alternative to FCM would be difficult

What would be alternatives for "other users"?

MQTT, or some solution based off of WebSockets, would be the two that I would look at first

I have not researched this space recently and so there may be some new options that I am unaware of

the challenge is that for any non-FCM solution, you somehow need a process to be listening for messages all the time (e.g., listening on the client side of the WebSocket)

that would require a foreground service (to avoid Android 8.0's limitation on background service lifetime)

and it would require the user to opt out of all battery optimization for that app

With "WebSocket" you mean like implementing a Server such as AsyncHttpServer?

no, I mean WebSockets: https://en.wikipedia.org/wiki/WebSocket

Oh okay, my bad.

Thank you for this. What about "s PHP a good back-end for sending messages or should I learn to do it with JavaScrips, such as Node.js?"

that depends on how you send the messagess

er, messages

if you are using FCM, by now, I imagine that there are server-side libraries for all major frameworks

I would be rather surprised if there is no solution for PHP -> FCM communications

that being said, I have never used PHP

if you are using MQTT or WebSockets, your options may be more limited, and you may need a richer server-side option (NodeJS, Kotlin, etc.)

So in general there is no much difference right? I am only asking as I have seen implementatons of both and many ppl in general these days migrate from PHP to Node.js solutioins

PHP is rather old, and AFAIK you can "hit the wall" on technical limitations rather quickly

NodeJS is more capable, but it does require some amount of JavaScript experience

So would you suggest for me to learn how to do "server-sided" operations in Node.JS in general?

I can't answer that

I can provide guidance on Android app development

I cannot tell you what is best for you for server-side development

personally, nowadays I use Kotlin, and before that I used Ruby

Aha, okay. I was going to ask you whether I should replace my Retrofit -> PHP -> MySQL with something connected to Node.JS but I guess you cannot answer that aswell

NodeJS is popular, and that has advantages

the Retrofit side is fine!

if your PHP works and you are happy with it, there may not be any reason to change

Hmm, it certainly works but for some reason I am obsessed with doing "things optimally". Which is also the reason why I am asking you this

you may be familiar with the expression: "beauty lies in the eyes of the beholder"

And if there would be adventage to use Node.JS, I would certainly learn it

what you consider "optimal" is your choice, based on your criteria and your opinions

I can't tell you want you will find to be optimal

I see. Thank you for that answer, I probably should get rid of "black and white" optimisations in programming

As, like you've said, there is no such thing

it's more that personal opinions are personal

my opinions are my own and may not resemble yours

Thank you for this answer

In addition to everything, I would like to add chat functionality to my app. After a bit of research, I have found that Firebase is supposed to be the best for real-time messages. However, many users advised againts using it due to it's costs when scalled to many users. So, what is your thought on this topic? Should I opt for Firebase or go for an alternative?

IMHO, that depends a bit on how the chat will work

if you only need to receive chat messages when the app is in the foreground, then FCM would be overkill, and I would use WebSockets

if, on the other hand, you want to continuously receive chat messages, even when the app is not running, FCM (for Google Play devices) may be necessary

FCM mostly exists to deliver messages when your app might not be running

I see. What about database/storage perspective? Many people reccomend Firebase database while also there are costs one needs to consider.

if by "Firebase" you were referring to Firestore or Firebase Realtime Database... I only worked with Firebase Realtime Database and did not like it much

I was reffering to database yes

Sorry for inconvenciance

no problem -- there are lots of things under the Firebase brand

personally, I would not use Firebase services, but that is because I am "a control freak" and prefer to run my own servers

it helps that I have decades of experience in running servers

I see. So what alternative (for DB side) would you use instead?

well, the Warescription app server is written in Kotlin and stores its data in SQLite

SQLite is not a good choice for a busy server

my server is not that busy

In additon, SQLite is for internal storage. What about hosting online DB?

if I needed a more powerful database, MySQL, MariaDB, or something like that would be candidates, though I have not researched this area recently

SQLite can be used just about anywhere

I have used it on servers for over a decade

but, you need to run your own server

Oh, I did not know that. Thank you for that information

personally, I have never used a hosted database service, other than about a month's use of Firebase Realtime Database

SO all that being said, you would advice me against using Firebase DB and instead rather roll my own implementation of DB?

no, I am merely saying what my experiences were

Okay, will try to do some more research on that part then

Will be right back: grabbing water

Sorry for taht

no problem!

I have a question regarding app debuging: at this point, I am only using my phone to debug while using LogCat. I have seen that in your book you go through many debuging tools. Would you reccomend to start using these and which one/two would you reccomend?

I am not certain what tools you are referring to

on a daily basis, I use the Android Studio debugger, plus Logcat

periodically, I use Leak Canary and Android Studio tools for leak detection

I think at one point you mentioned Espresso/Mockito(?)

those are testing libraries

those are not really debugging tools

other than to the extent that tests help you find bugs, of course

Oh, my bad. Would you reccomend me using these?

some sort of mocking is very useful in testing, and I have settled on Mockito, though there are others (e.g., PowerMock)

Espresso is very useful in UI testing, but I find those sorts of tests to be fragile, so I try to minimize how much testing I do there

So what do these "testing libraries" tell us that Android Studio cannot?

they are independent of Android Studio

that is akin to asking "what does an Android app do that Android Studio cannot?" -- they are not really comparable technologies

instrumented tests and unit tests exercise our production code to confirm that we wrote it correctly

But doesn't just running the code on the emulator tells us the same thing?

not necessarily

for example, you seem to want to communicate with a server

suppose this is a REST-style Web service

you need to know if your app can handle unexpected Web service responses (e.g., HTTP 500 return code)

manual testing probably cannot test that

so, we write test code that can simulate the server and return responses that our tests need, to see if our code handles those sorts of responses

software testing is a major portion of any sort of software development

Oh I see. So for this purpose, you (personally) mainly you Mockito correct?

in some of my books, I show how to test Android apps, but I assume that you have learned about the concept of software testing from someplace else

in terms of writing mocks, yes, I mostly use Mockito

though for Web service responses, I sometimes use MockWebServer from the OkHttp library

And for "UI testing", what did you mean with that?

you were saying that you do manual testing: poking at the UI and seeing what breaks

UI testing is automated "poking at the UI and seeing what breaks"

so, with Espresso, you can say "click this button", "fill in XYZ into this field", and so on

Oh I see. Thank you - will try to use these during my next tests then!

then examine the state of other widgets to see if things worked (e.g., "confirm that the 'Save' button is now enabled"

So, the last question: in one of your books, you describe GraphQL in detail. So far, I have mainly used Retrofit to do the comparable requests. Would you reccomend using GraphQL over Retrofit in general?

Or this again depends on many factors?

comparing GraphQL to Retrofit is not quite the correct comparison

you might compare GraphQL to REST

Er correct, I see the destinction

so, if your server is set up to have a GraphQL endpoint, you would need to talk to that from the Android app, using something like Apollo-Android

just as if your server is set up to have a REST endpoint, you might use something like Retrofit

what you use on the device is controlled by how the server is implemented

in terms of whether you should use GraphQL or REST on the server -- again, I cannot really provide recommendations there

GraphQL has some interesting characteristics, but REST is much more common

I got to know that GraphQL might be much better in scenarios for doing 1 query instead of many

So i guess that if I have many such queries replacing REST might be worthwile

Otherwise not

Do I have correct idea?

yes, usually it is easier to get all your data in one request-and-response with GraphQL

GraphQL can offer better performance as a result, but it is going to be more complex to set up

partly, it will be more complex simply because it is newer and has less support in terms of libraries, tools, and knowledge

partly, it will be more complex because that complexity is what enables the powerful query language

for a personal project, unless you really wanted to play with GraphQL, I would lean towards REST

So would you agree with my theory of using GraphQL where i have to perform multiple queries and otherwise using REST*

well, usually, you implement either GraphQL or REST, not both

I have done everything with REST so far but *again* i would like to learn "optimally"

there are many facets to "optimal"

so, GraphQL might perform better in some apps, but it will take more development time

whether you need that extra runtime performance will help determine how much the development time cost is worth it

for a personal project, since performance is rarely an issue, REST is the simpler solution, on the whole

so, for example, the Klassbook (https://klassbook.commonsware.com) uses a REST Web service, not GraphQL

and that's all the time I have for today -- I have to take a call in two minutes

Thank you Mark, you have helped me much agagin

you're welcome!

the transcript will be posted to https://commonsware.com/office-hours/ shortly

Hopefully I will leave you in peace for a few weeks

have a pleasant day!

have a nice rest of the day

:_)