Trouble Compiling my first app

The code server allows bigger apps.

Unfortunately, the Build also failed there:

[GenerateClasses] INFO: Source File: appinventor/ai_agetzler/AirCrete_House_Calculator_checkpoint7/Screen1.yail
[GenerateClasses] INFO: Source File: appinventor/ai_agetzler/AirCrete_House_Calculator_checkpoint7/Planning.yail
[GenerateClasses] INFO: Libraries Classpath = /tmp/kawa6029271810648649515.jar:/tmp/acra-4.4.01128535654752018386.jar:/tmp/AndroidRuntime8055132596105454037.jar:/tmp/annotation6705243415651411155.jar:/tmp/appcompat2267850724925151967.jar:/tmp/asynclayoutinflater2261689151567779166.jar:/tmp/collection1247551692845104203.jar:/tmp/constraintlayout6156472927175366880.jar:/tmp/constraintlayout-solver8775059757183206870.jar:/tmp/coordinatorlayout850145535523815776.jar:/tmp/core2080351907319770954.jar:/tmp/core-common8678263987629148668.jar:/tmp/core-runtime846605179615721455.jar:/tmp/cursoradapter2141530129730577917.jar:/tmp/customview572696782772940808.jar:/tmp/documentfile8712513835018224718.jar:/tmp/drawerlayout193087660051464310.jar:/tmp/fragment5160898168785254321.jar:/tmp/interpolator4321980535525475929.jar:/tmp/legacy-support-core-ui5564181463097158312.jar:/tmp/legacy-support-core-utils2916827933987910259.jar:/tmp/lifecycle-common6908826642034904816.jar:/tmp/lifecycle-livedata8148252907528307687.jar:/tmp/lifecycle-livedata-core8417599791531591362.jar:/tmp/lifecycle-runtime5321038549778894304.jar:/tmp/lifecycle-viewmodel4331026044786784019.jar:/tmp/loader731854094611997490.jar:/tmp/localbroadcastmanager4925395246810185668.jar:/tmp/print6548415070559496459.jar:/tmp/slidingpanelayout3670555983936209900.jar:/tmp/swiperefreshlayout5435291541766960701.jar:/tmp/vectordrawable7295966984868860606.jar:/tmp/vectordrawable-animated5642522570096453315.jar:/tmp/versionedparcelable372237762338400009.jar:/tmp/viewpager6482202273227026758.jar:/tmp/1703106428271_0.729563007543488-0/youngandroidproject/../build/classes:/tmp/android8436150708758657530.jar
(compiling appinventor/ai_agetzler/AirCrete_House_Calculator_checkpoint7/Screen1.yail to appinventor.ai_agetzler.AirCrete_House_Calculator_checkpoint7.Screen1)
(compiling appinventor/ai_agetzler/AirCrete_House_Calculator_checkpoint7/Planning.yail to appinventor.ai_agetzler.AirCrete_House_Calculator_checkpoint7.Planning)
(compiling /tmp/runtime8612870397540384625.scm to
[GenerateClasses] Task succeeded in 6.289 seconds
[RunMultidex] Starting Task
[RunMultidex] ERROR: DX returned an error code
[RunMultidex] Task errored in 39.209 seconds

You have many blocks in the Planning screen.
It bears further review.

Unfortunately there is too many if statement, if disable this procedure it builds just fine on regular server.


unfortunately I can't even zoom out to see the whole thing

1 Like

Hmmm... I will see if I can thin the if statements.. Who knew logic was limited..

1 Like

This app is in serious need of table driven logic.

That would shrink the block count considerably, and increase flexibility in the face of price and material changes.

What might that look like?

This is table driven, though I am using TinyDB NameSpaces to store my tables:

Notice how my Designer knows nothing about the fruit I sell.

Because of the many line items in your app, it would be worth your while to set up some cost tables in a Google Sheet, in preparation for studying how you would build a customer order into one or more sheets.

Perhaps I should just build a list with the item name, price. and quantity. Then I can index my way through to display everything in a textbox. However, I'm not sure how to go about making provisions to enter new prices for items displayed..

That's why I like Google Sheets:

I guess that's what I'm not following. The user needs to be able to enter pricing from their area and not affect change for other users..


For individual pricing, you could use TinyDB NameSpaces to keep prices in the phone, like in my Fruit Stand sample.

Alternatively, if you want a subscription model, you could set up individual sheets of prices named by user.

The internal class representation for Java and Android are mostly 16 bit, so the length of many things like methods tend to be 65535 bytes (2^16 - 1) in terms of individual instructions. One block might translate into many instructions at the App Inventor level. Some programming camps focus on things like computational complexity scores to indicate when methods become so complex to reason about that they should be broken down into smaller units. But as ABG has suggested, a lookup table (possibly loaded from a shared resource so you can update it independent of the app) would be a likely solution to the problem.

Here is a sneaky and lazy way to save and recover every text box you laboriously coded into your app...

Each text box has a Hint attribute, that you can set up unique and helpful, and hopefully suitable as a TinyDB tag.

There is an Every Textbox block that will return a list of every textbox component in the current Screen. Using Generic (any) textbox blocks you can loop through that list and

  • test the hints and text values for 0
  • load and save the text values from and to TinyDB using as tags the unique hints coded into the text boxes in the Designer
  • set visibility depending on .Text value
  • pair them with Labels whose text can be matched against the textbox Hint (give or take a trailing colon) for row-wide visibility control

You need lot of patience to build such a long table in the designer view. :+1:
But this can be done by dynamic component extension like CompCreator.

The overly long procedure can be broken down into subprocedures called from the original procedure husk.

That should circumvent the procedure size limitation.

I like that idea for indexing the hints. However, really the essence is to only display items on the shopping list with non-zero quantity. This could be solved by simply outputting a sting into a text box. But then How do I edit the quantity of a long list without a floating text box? It does not appear possible to use a notifier to pop up a number-only input box. SO perhaps I could grab a sting and check for numbers only.

I need to do the input-output over probably. I thought I might use your idea and place a small icon beside each output line making the alt-text the index value. Then when clicked on I could unhide an input box to get the new price associated with the item clicked.

The real pain here is the lack of ability to dynamically generate textboxes or place images into the output text programmatically. Which means another long period of dropping images into the designer.

That could be very helpful. Especially binding a click to a label. Thankyou.

Regarding all those text boxes, consider the question of how many doggy doors do you need for a kennel?

Text boxes can be reused.

Here is a sample to study, where the same text box can be used to input many attribute values...

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.