Your comments
A one-time app in our system is not dependent on our system to service in-app purchases or push notifications, so your bandwidth would be controlled by Apple and there would be no limit.
Our subscription plans in the Studio maintain a 150GB/month bandwidth limit on push messages and in-app purchase usage. If you go above this limit, you would be charged additional fees.
Our subscription plans in the Studio maintain a 150GB/month bandwidth limit on push messages and in-app purchase usage. If you go above this limit, you would be charged additional fees.
You App would remain in our system as well as any IPAs you have built would stand on their own.
Depending on the functionality you have in place, the only thing that could be at risk is the availability of your In-App purchase wires stored inside of the App Creation Studio.
You would also no longer have push capabilities inside of your App.
Depending on the functionality you have in place, the only thing that could be at risk is the availability of your In-App purchase wires stored inside of the App Creation Studio.
You would also no longer have push capabilities inside of your App.
Tyler,
The challenge here is that a list, pager or tableview has its scroll defined based on the size of its contents, when you scale or change that content, then the scroll becomes invalid.
Your best bet is to not use a pager and build out your column view with panels instead.
I will try and create an example for you.
The challenge here is that a list, pager or tableview has its scroll defined based on the size of its contents, when you scale or change that content, then the scroll becomes invalid.
Your best bet is to not use a pager and build out your column view with panels instead.
I will try and create an example for you.
Using a sync block inside of your action will allow you to use a delay attribute.
No I am saying that if you use the superwire inside of a play action from your subwire you can trigger an action inside of your main.wire to control the toolbar stored in your main.wire as well.
In the example above your subwire would have an onclickup="close" on your PDF tag and that close action would play a show toolbar action inside your main.wire.
In the example above your subwire would have an onclickup="close" on your PDF tag and that close action would play a show toolbar action inside your main.wire.
The issue here would be how you load your subwires and handle the main.wire. Generally we unload or alpha out the main.wire to make room for the subwire to sit inside of an include that is 100% x 100%. In this case, you could not remove the main.wire and still have a subwire drive the show toolbar action from the pdf sitting in your subwire. This would be done with the superwire option, the same that you would use to fire a close issue action sitting on main.wire from a subwire.
If your main wire only houses the toolbar portion, then it shouldn't end up being an issue of overlapping objects since it would translate in and out on top of the include content. You may have to use the set action to move the toolbar tofront every time.
<action name="close">
<play action="close-issue" superwire="yes" target="../.." />
</action>
If your main wire only houses the toolbar portion, then it shouldn't end up being an issue of overlapping objects since it would translate in and out on top of the include content. You may have to use the set action to move the toolbar tofront every time.
You would need to move your toolbar into each of your subwires and the identify certain touch points that will close the issue and return you to the main.wire.
They really should not be, you may consider making their clickable areas larger.
Customer support service by UserEcho
Can you confirm this is still an issue? And provide your App's ID.