Hi
I am getting keener and keener on backendless and am going thru Marks tutorial of creating a todo list to show how all of crud works. But when I get to the logic of binding the check box my options are different from Marks.
Marks
Mine
Everything up to this point has worked exactly as Mark described.
Are you able to let me know what have I missed??? Or how do I use the options I have to bind to the underlying table?
Kind Regards
BruceX
Hi Vlad
Thank you Vlad for replying so quickly, that got me through. Slight differences between the version of Backendless in the tutorial and the current version seem to stop me more than I wish. However, now I am up to the next conundrum.
In the todo tutorial Mark shows how to delete a record via a delete button. The delete button is inside a Cell, which is inside a dynamic Row, which is inside a Container (called todoList). But the logic screen Mark has for the button is different to mine. At the top of Marks screen there is an object called ‘Row1 Data’ , mine shows ‘ToDoList Item Data’.
I have redone the tutorial 2 times up to this point and got the same result and I have persisted past this point hoping that ‘ToDoList Item Data’ is a synonym for ‘Row1 Data’ . But it does not work out. The row data to be deleted does not get deleted.
I cannot spot where I went wrong, can you help please.
Marks button logic screen
My button logic screen
Kind Regards
BruceX
Hi Vlad
I gave the above another effort and managed to find the work around.
The logic in the tutorial needs to be changed to…
BruceX
Hi @Bruce_X,
The only difference between the video and the current implementation in UI Builder is the Row1 Data block is now referenced as toDoList Item Data (or instead of toDoList, it may be whatever id you assigned to the container). I believe this change makes logic programming more intuitive as it clearly states where the data model object (i.e. the xxx Item Data object) is coming from. Previously when it said Row1 Data, it was not intuitive at all.
Yes, ideally, the video needs to be re-recorded, however, I believe it is such a minor and intuitive change (visually speaking) that it doesn’t warrant a complete re-record.
Regards,
Mark
Hi Mark
Wonderful to hear from the man himself. I did figure that much out and completed your tutorial.
I am very impressed with the quality of backendless, both the database and the UI builder.
I have a couple of suggestions, and I know I am risking being very naive saying this.
The Delete Logic and the Add Logic is overly complicated (in my view). You even commented on that yourself in the tutorial.
Take the Add Logic
Trying to coordinate the on screen list with the underlying database records would be bug prone, (also, until I get used to UI Biulder more, I find it unintuitive). It might be easy to avoid bugs on an easy form like this, but bigger, more complicated forms would definitely bring out a bug proneness.
All the logic in the red circles could be replaced by a refresh from the database, that way the developer (me) is guaranteed that the onscreen matches the database.
Take the Delete Logic.
I have no idea if you already do this in later tutorials, brilliant if you do, otherwise I hope this makes sense, I know it would make ui builder even easier for me.
Bruce X
Hi Bruce X,
Thank you for your kind words.
Yes, I agree it is not very intuitive and you’re right in saying that the logic can be substituted by forcing a refresh from the database. The reason I do not like that approach is that I believe it would be showing a “bad practice” for people who learn how to build UIs. Let’s see what happens from the UX perspective if the logic is to refresh the data from the database:
Suppose you have a longer list of items. In our app these are “todo” items, but in reality, it would be a list of orders, customers, users, etc. You could’ve scrolled to pages 2, 3, N, used some filtering, sorting, all the typical things users do in the UI. If there is a refresh in the database done in the logic, yes, the deleted item would disappear from the list, but then you’d have to add ALL the logic for restoring the app’s state to make it less painful to the user (i.e. navigate to a certain page, apply filtering, sorting, etc). That in my mind is way more complex (and prone to bugs) than simply iterating over the objects in the data model and remove the ones not needed. Just my $0.02 
Regards,
Mark
Hi Mark
I agree completely with your answer. Maintaining currency would not be a piece of cake, and it would be a mistake to put that in the developers (me) hands with logic blocks.
If the refresh could be done it would have to be automatic, ie under the covers from the likes of me. The Refresh would have to inherit all the ‘features’ of the original list (ie filters, sorting etc) and still get the right currency. I know it is a big ask, so please do not take this as a serious criticism, your tutorials are great, you have hit the right pace and detail, and so far I really like backendless. Roll on the next one.
Kind Regards
BruceX
