I suspect the Runtime Error … Invalid destinationAddress might be a problem with accessing your database of registerd phone numbers.
How are you testing this? Using Companion or a compiled app? Here is what the tutorial says
" The app works great so far, but if you’ve completed some of the earlier tutorials, you’ve probably guessed that there’s a problem: if the administrator closes the app and relaunches it, the broadcast list will be lost and everyone will have to reregister. To fix this, you’ll use the TinyDB component to store and retrieve the BroadcastList to and from a database." You might not be doing that.
Also, this could be an issue with communication to your database. Are you using a TinyWebDB or something else?
What were you doing when the Runtime Error appeared? Loading the app? Sending a Text from the app or something else.
I am using a compiled app and i’m using the **Tiny DB ** component to store and retrieve the broadcast list and it works perfectly but only if the app is running even after setting the receiving enabled properties to 3.
The app wasjust received a member onto my phone when the error showed.
The picture is not uploading for reasons unknown
You modified the original tutorial a lot. I can’t test your code so for whatever it is worth, here are some comments:
The cause of the Runtime Error when “The app was just received a member onto my phone when the error showed.” is probably related to using a text block in the Screen1.Initialize tinydb1.GetVAlue valueIfTagNotThere instead of a required create empty list Block. Do I know for sure? Of course not. I can’t test your app; not having a second phone to test with among the issues. This also could be your failure to check if the valueFromDB is a List.
You use a TextToSpeech Block in your addNumberToGroup Procedure; sometimes using that block causes timing issues. As an experiment, I would disable it and see if performance improves.
You said "
I am using a compiled app and i’m using the **Tiny DB ** component to store and retrieve the broadcast list and it works perfectly" - obviously not.
I am surprised to see you use a call textingSendMessage instead of a textingSendMessageDirect. The purpose in using a Companion with a u in it is to be able to send texts automatically; isn’t it?
" but only if the app is running even after setting the receiving enabled properties to 3." does ‘app is running’ mean when the device is turned off or when it goes to sleep. The tutorial was written for use in a seminar; I guess the intent of the app was to keep the app active so others could use the hub. To use your cell as a hub, you might need to code a StayAwake routine to prevent it from going to sleep. Why a ‘3’ is not working I do not know…it might not be working because of other coding issues identified.
Using either an extension or a block routine drains your device battery rapidly . These work around methods are not running the app in the Background, they force the app
screen to stay open.
As long as this window is visible to the user, keep the device’s screen turned on and bright.
Note: If the screen of the device is on, this will obviously drain battery of your device! Please use this method wisely! You might want to use this method together with the Settings extension to adjust the brightness of the screen.
Sponsor of this method is Joerg. Thank you!
Calling this method will cancel the KeepScreenOn flag.
The recommended option is to Leave Use Legacy Connection unchecked. Some users have difficulty using the Companion if they do not use Legacy. Legacy provides the Companion behavior that existed prior to several months ago. Most users do not need to check that Block.
You do not need to pick any of the options shown for Taifun Tools. Just go to the Block editor now that the extension is installed. Use the indicated blocks to keep the screen awake.
If you are not comfortable doing this with Taifun’s extension, you can use blocks ( How to keep the screen on ) instead of the extension. I use the Blocks for StayAwake and it works great. No need for the extension.
Yes, you need to experiment. Make a new Project as a test to learn the too. Experiment, just to keep the screen from sleeping and see how the tool works . Once you are confident it works, finish programming your Broadcast hub app.
A stayawake routine might allow you to set ReceivingEnabled properties to 2 instead of 3 . The app will ‘run’ constantly, especially if you keep your device’s charger plugged in. The app will not go to sleep while stayawake runs so ReceivingEnabled Foreground (2) should work fine instead of Always (3). Experiment to see what works for you.
The texting component is working perfectly.Although I do not have many phones to test it’s capability due to the current happenings in the world.I will like to add some additional features such as only people from a particular country can join.Any ideas on how to do that??
Congratulations . Would you like to share your aia with the forum? Others certainly are interested in what finally worked.
How to restrict usage depends partly on your existing code.
Restrict phone numbers to those with a particular country code or area code possibly. Only allow those to 'register' if their phone number's first several digits matches particular criteria perhaps. The Texting.MessageReceived event handler can identify the number of the phone registering. Use a conditional statement ... if number contains xxxx then it is ok, if not then cannot register.
