Copy data and blocks to an other screen


#4

Ok sir thanks… i will try this


#5

https://www.youtube.com/watch?v=XvSiD-iA17Y

can i do this to appybuilder
in this video its showing that we can copy any screen components by editing aia file of apk in computer and replacing the screen name


#6

https://www.youtube.com/watch?v=XvSiD-iA17Y1

sir, i saw your video on screen manipulating… can I use this method to copy screen in appybuider.


#7

@Chetan_singh Your post was merged into this thread.


#8

As an advice, don’t go crazy duplicating screens. If you have to duplicate screens, chances are you are wasting resources. Instead you can build a screen that acts as a template and loads different content or information depending on the users interaction. As an example, the Google Play Store doesn’t have one screen per app listed. Instead they have a blank one with image placeholders, labels, etc and fill those according to the user’s selection.


#9

if u don’t know anything, then don advise anyone.
and one more thing.
my app is all about copying screens.


#10

@Chetan_singh members are trying to help each other. Please respect each other. Thanks


#11

@Italo gave you a very wise advice…
see also tip1 here General Tips and Tricks for App Inventor/AppyBuilder

Taifun


#12
  1. There are posts elsewhere that detail the process of editing an .aia in place. I do this all the time. If doing it this way, copy and rename the matching .bky and .scm files.

  2. It is very easy to break your app by doing this, as the AI 2 parser is very sensitive to malformed XML and JSON. Unless you really understand the content and structure of these files, don’t edit them outside of the normal AI 2 web environment.

  3. Bluntly, multi-screen functionality, in my opinion, is broken. I wrote a very simple app with 5 screens and minimal graphics, and my app crashed continuously due to memory errors. Doing exactly the same thing after reducing it to three screens eliminated the crash. I wouldn’t plan on ever building an app with more that 2-3 screens at this point, at least until AI 2 figures out the architectural design issue triggering this instability (and it seems pretty clear that they have no interest in doing so, as it has persisted for years).

So, yes you can, and you’re wasting your time off you do.


#13

:thinking:

Good luck with that!


#14

well. you have to switch screens correctly…
see also The recommended method of switching screens in App Inventor

Taifun


#15

@Taifun - you know I did exactly that. You saw the code, admitted it yourself.

It’s broken. Even when you do it correctly. It is absolutely clear that there’s a memory leak, that when you “close” a screen, the allocated memory is not all (if any) being released. Open too many different screens, no matter how many you’ve previously closed, and your app will crash. It is totally reproducible. I bet I could create an app with twenty screens, and it would run fine as long as I only opened up (and closed) two or three. The “close screen” advice works because when you don’t “close” a screen, a new one is opened, instead of the old one being reused, and you reach the “too many screens opened” threshold faster. The problem isn’t “too many screens open at once”, but rather, “too many screens opened, once”.

The best advice is: don’t do it. Period. You’re just setting yourself up to have to undo it later. In my opinion, MIT doesn’t care about fixing it, because anyone who runs into the problem is by definition not their target audience: beginners, and because everyone else can work around the problem by simply not using the feature (however convenient it is).


#16

@Thomas_Leavitt how many screens do you have? Are you saying that even if you have few screens, going back and forth will eventually create issue, even in MIT AI ?


#17

No, I’m saying exactly the opposite. Add enough screens to your app, with enough data, and it will crash. But ONLY after you open the Xth screen, and opening the Xth screen is the problem. My crashing app could open and close three additional screens all day long, but the MOMENT the 4th screen was opened, it would crash. Altering the order in which screens were opened made no difference, it was the simple fact of opening a 4th screen for the first time that crashed my app. I’m certain my app could have had twenty screens, and as long as I never opened more than three different ones in a single session, it wouldn’t crash. I’m convinced that closing a screen doesn’t actually free up any memory, it simply prevents new memory from being assigned when it is reopened (effectively acting the same as opening up an additional, different screen in your app).

I haven’t tried this in MIT AI 2, no, but I’ve seen enough reports, and I’m pretty sure AB’s core code base hasn’t deviated far enough from MIT’s for there to be a difference on such a fundamental design issue.


#18

Please prepare an example as small as possible, which demonstrates this issue and add the project (aia file) into this thread together with exact instructions for how to elicit the error, so someone can take a look

Taifun


#19

@Thomas_Leavitt, actually i have build a very complex app with about 13-14 screens. I agree that some need to be tuned like timer and GPS sensor based calculation not working really well in multiscreen, but otherwise the app runs pretty well and smooth…


#20

Are’t you a bit off topic with @Thomas_Leavitt inquiries, It should be joined with this one

Boban


#21

@Ronin I don’t doubt it, but I’ll bet your app’s design side steps the memory usage problems; I’d guess the issue is less the number of screens, and more the total amount of memory utilized by those screens. Does the app in question have a significant number of embedded graphics? When I stripped the graphics out of my 5 screen app, it ran without crashing; the graphics weren’t particularly large (just buttons, fonts and a background image) but they obviously increased the footprint of each screen enough to trigger resource exhaustion. The same set of images loaded into a smaller number of screens (thus less duplication in memory and a smaller total allocation footprint, I presume) running essentially the same logic eliminated the problem.


#22

Ok, @Thomas_Leavitt, @Boban_Stojmenovic is right. We are off topic here


#23

Just out of curiosity, what kind of app needs 13 screens? Do you have a link to try it?