Apple just rejected my app due to using "private api" related to status bar overlays. However, I only on MTStatusBarOverlay library for the status bar overlay.
Is MTStatusBarOverlay forbidden by Apple? MTStatusBarOverlay should be included in some apps on app store, as stated in their Github page.
Below is the only place I called MTStatusBarOverlay library:
+(void) displayMSGOnStatusBar:(NSString *)msg
{
MTStatusBarOverlay *overlay = [MTStatusBarOverlay sharedInstance];
overlay.animation = MTStatusBarOverlayAnimationFallDown;
overlay.detailViewMode = MTDetailViewModeHistory;
[overlay postImmediateMessage:msg duration:1.5 animated:YES];
}
Anyone know where the issue is? Your suggestion/help will be greatly appreciated!
Just couple of thoughts:
a) Approval process doesn't guarantee to catch 100% of offending behavior. So, they may rejected your app, but they may have approved app which did very similar things.
b) MTStatusBarOverlay was actively developed about a year ago. It could be that Apple approval guidelines changed for this period of time.
c) Based on the description of rejection, they reject exactly the behavior of MTStatusBarOverlay (they don't like overlays on top of UIStatusBar).
Related
I'm implementing a meeting app that uses Amazon's Chime SKD React. Here is the
link of the library. I successfully implemented a meeting, and it works well. However, there is a small issue which with which I'm not satisfied.
There are several meeting statuses that Chime provides.
Here is the enum of the meeting status:
enum MeetingStatus {
Loading,
Succeeded,
Failed,
Ended,
JoinedFromAnotherDevice,
Left,
TerminalFailure
}
These statuses are managed by the useMeetingStatus hook from the SDK itself. I think the statuses are pretty much self explanatory.
You enter a meeting, you get the MeetingStatus.Succeeded status. You leave the meeting you get the MeetingStatus.Left status.
And here is the problem:
Once you leave a meeting and try to enter a new one, you get for a moment MeetingStatus.Left status, and then you get the initial meeting status which should be MeetingStatus.Loading.
So my question is, is there a way to reset the meeting status after the user leaves a meeting with the meetingManager.leave() method?
I also noticed after leaving a meeting and hard reloading the app (page), this doesn't happen, which for me means, there is some state that should be reset after leaving a meeting.
There is a <MeetingProvider> component which wraps the the meeting app. This meeting provider holds all data in the useMeetingManager hook. The solution was to re render the <MeetingProvider> which I did by wrapping the router component with it.
Once the user leaves the meeting, the app redirects the user to other page and the <MeetingProvider> re renders.
Or, there is also a solution to instantiate a new meetingManager object like this:
const meetingManager = new MeetingManager(new ConsoleLogger('LoggerName'));
and then you pass the meetingManager to the <MeetingProvider> like this:
<MeetingProvider meetingManager={meetingManager}>
<MyApp1 />
</MeetingProvider>
This is described here
I am building a React app (with react-redux, redux-saga, and axios), and
I need advice on how to arrange my project for displaying user-friendly error messages.
(It is up to me to decide what and how I display to the user)
In particular, I would like to get answers to the following questions:
Should I display a message based on the status code?
Should I break down the errors to client / server / other errors and what are the benefits of that? (based on example from Axios)
Where should I keep the error messages, in the component itself, in a config file (I would like to see an example of such a file)?
How would my redux state tree look?
Should I dispatch an action for every error based on the status code?
I would appreciate any suggestions or real-world examples.
Here are some examples of error responses from our backend:
Request URL: https://example.com/api/call/123
Request Method: POST
Status Code: 400 Bad Request
Request URL: https://example.com/api/call/123
Request Method: PUT
Status Code: 409 Conflict
Request URL: https://example.com/api/user/me/
Request Method: GET
Status Code: 401 Unauthorized
It basically depends on what method you are trying to display the message, For instance, in our own projects, We are using a global snack bar component to display errors if any have occurred during the requests.
Most of the time users don't care about the status code, if you want not to be very specific then you can display a simple alert/snack bar for example: "Sorry, Some error occurred".
If you are sure that you do need to show specific errors to the user the I definitely recommend a constant file for errors which will store all your error message, You can keep them in constants directory in the store folder so maybe even in /helpers, It depends on your choice.
Yep, you can definitely divide your errors based on if the error was on the server or the client-side.
I don't think the redux tree will change if you're not managing errors in the tree. If you want to, definitely use a snack bar/alert reducer on the top of the tree
You may not want to show the same error for a status code in each of different components, Otherwise, if you want to, You can use it but that would add a lot of unnecessary code into your requests.
For our projects, since we are using i18 for internationalization, We have a snack bar reducer and the action folder, We import the snack bar actions in our sagas and just display a simple error message ( You definitely can customize it for your needs accordingly), That's all,Keep it simple.
yield put(Actions.apiRequest);
try {
const res = yield axios.put('/todo/', updateData);
if (res.data.status === 'success') {
yield put(Actions.fetchTodos(todoID));
yield put(snackbarSuccess('Todo Saved Successfully !'));
} else {
throw new Error();
}
} catch (error) {
yield put(Actions.apiError);
yield put(snackbarError(REQUEST_FAIL)); // an imported constant
}
Some basic code behind my implementation.
1) Assuming you're also doing the BE or can ask someone to adjust the response - It might be best to return a body with your API error response, and avoid just HTTP status codes - if possible. That could then contain an error 'code' that maps to a message on your front-end, as well as field name which can be really helpful for displaying errors in the right place on forms, etc. alternatively, the entire message could come from the BE and the FE simply display it. I work on an enterprise-level codebase that uses both these methods.
2) Regarding error message, i'd always store them in a common file but beyond that up to you really. It sort of depends on how you implement #1. Personally I like error 'codes' stored in an enum file, which correspond to a message because you can then do other logic from that (e.g. don't display the rest of a form if error X is triggered, use a custom message for the error code in one situation or fall back to a default
3) Not sure - I guess you'd do that if you want to log server-side errors but show client. Where I work we differentiate purely for different logging categories I think.
4) Again depends on your implementation - somewhat up to you. Some form packages will handle this for you in redux. Others will just use local state and not redux for this.
5) Would make sense to, yes. Again if you look a custom error code returned in the body of the API call that'll give you more flexibility.
I hope that gives you some ideas, based on my experience rather than any set way of thinking.
have a look at https://reactjs.org/docs/error-boundaries.html as well, and if you haven't already REST APIS / best practice for REST API: https://blog.restcase.com/rest-api-error-codes-101/
Speaking of mobile devices, whats the difference between those two methods? If I press the home key both are called. Is there any situation when one is called and not the other?
Since this UnityAnswer is one of the first (if not the first) to be
returned on a search for OnApplicationFocus/Pause & iOS, an important
update in Unity 4.6.1 has changed the behavior for iOS.
As of 4.6.1, both OnApplicationFocus and OnApplicationPause will be
called in iOS.
The order is :
App initially starts:
OnApplicationFocus(true) is called
App is soft closed:
OnApplicationFocus(false) is called
OnApplicationPause(true) is called
App is brought forward after soft closing:
OnApplicationPause(false) is called
OnApplicationFocus(true) is called
Hope that helps
http://answers.unity.com/answers/970958/view.html
Being new to Android development I have been researching StackOverflow for an answer to this question: How to mute the phone ringer for all incoming messages and calls when I am supposed to be in a Meeting as indicated by my Calendar.
I am able to access the calendar and able to check if present time is within the times set for an event. But how do I send any incoming phone calls to voice mail (and send a text message to caller).
I have gone through lots of questions here:
"How to detect incoming calls, in an Android device?"
"Incoming call broadcast receiver not working (Android 4.1)"
"How to detect incoming call with the help of Broadcast Receiver?"
"Custom incoming/outgoing call screen in Android"
"how to make an incoming call from our application"
"Android: Taking complete control of phone(kiosk mode), is it possible? How?"
"How to disconnect incoming call in android by programatically"
The ITelephony using AIDL looked promising untill I found out that it no longer works under Android 4.2 etc due to security issues.
At the moment the answer:
"How to detect incoming calls, in an Android device?" seems to be better simply because it seems to handle incoming calls in an elegant way - but the answer does not talk about how to (a) Silence the Ringer, (b) End the Call/Divert it etc - the example explains how to determine what state the phone is in at any given time. The other drawback seems to be I am struggling to unregister the listener function which means even after the example app has been terminated, the listener still seems to remain active and jumps into action whenever there is a call. Only way to stop that seems to be to restart the phone - which is very annoying.
The other aspect is that most of these questions are a year or more old and some of the old answers are no longer valid - as I mentioned earlier - the ITelephony looked promising but no longer works with new phones.
The Google documentation seems to suggest that a program can programmatically wrap up an answer to an incoming call in a SMS Text message by sending an Intent etc - but no examples anywhere and looks like the Google's documentation may be out of date (or I am reading an old version of it on the internet - though don't know how it is possible since I am using Google Search to find an answer.)
Silencing the ringer and stopping the incoming / outgoing call is still possible.
First, the example from "How to detect incoming calls, in an Android device?" is the correct way to detect the incoming call.
Now, for silencing the ringer and stopping the call:
First, create an interface named "ITelephony" under the "com.android.internal.telephony" package:
http://i.stack.imgur.com/UQoVc.png
And add this code to the interface:
public interface ITelephony
{
boolean endCall();
void answerRingingCall();
void silenceRinger();
}
Then, on the method where you want to silence the ringer and stop the call, add this code:
//TelephonyManager
TelephonyManager telephonyManager = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
// Get the getITelephony() method
Class c = Class.forName(telephonyManager.getClass().getName());
Method m = c.getDeclaredMethod("getITelephony");
// Disable access check
m.setAccessible(true);
// Invoke getITelephony() to get the ITelephony interface
ITelephony telephonyInterface = (ITelephony) m.invoke(telephonyManager);
//Invoke silenceRinger
telephonyInterface.silenceRinger();
// Invoke endCall()
telephonyInterface.endCall();
Finally, in your manifest, you need to add these permissions:
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS" />
<uses-permission android:name="android.permission.CALL_PHONE" />
<uses-permission android:name="android.permission.MODIFY_PHONE_STATE" tools:ignore="ProtectedPermissions" />
I have tested this code on many devices and it works, if you have any problem, feel free to ask me :)
The silverlight object tag accept an 'onerror' parameter which calls back to a piece of javascript of your choice. The default implementation which is generated by the Visual Studio template assembles a descriptive message and throw it as an Error (which lets e.g. IE display the little warning triangle).
It seems to me that each time this callback is fired our silverlight instance is dead and you need to refresh the page. Is this a reasonable deduction?
Another issue is how to best handle this callback. Showing the little warning icon is somewhat developer-centric and it doesn't allow us (the developers) to discover what is actually failing in production when it is run on a customer machine. What are people doing with this? A couple of our own (more or less concrete) ideas are:
Send the error message back to the server via some exposed endpoint
Remove hide the silverlight object, show a nicer and more descriptive message to the user and a 'refresh' link to start up the silverlight page again (we run a full-sized silverlight application so if the silverlight object isn't working, the customer might as well reload anyway)
Somehow reload the object tag automatically to avoid having the customer perform any actions to get going again (perhaps combined with some notice to the customer that the 'system' restarted)
Ideas, thoughts, best practices, anti-patterns? What are you guys doing (except ensuring that the silverlight app never fails, but that's another discussion)?
I like a nice error reporting in the form of a "form" using SilverlightFX grab the source http://github.com/NikhilK/silverlightfx/tree/master , check it out very cool framework otherwise basically would be just a summary of the error, the ability to send it via upload that emails to support and an "oops we goofed" title :) I handle all unhandled expetions in this way, there is also a nice article on handling the errors by type using a dictionary
http://www.netfxharmonics.com/2009/04/Exception-Handlers-for-Silverlight-20 also a favorite of mine
. Hope this helps
I recommend you change how you're instantiating the Silverlight control. Instead of using the object tag, you can call Silverlight.CreateObjectEx() in the Silverlight.js file. This is probably a little more natural for your scenario. If it fails, you can call it again which is simpler than trying to reload object tags. Ex:
Silverlight.createObjectEx(
{
source: '/../VideoPlayer.xap',
parentElement: document.getElementById('movieplayerDiv'),
id: 'VideoPlayer',
properties: {
width: '100%',
height: '100%',
background: '#FFd9e3d7',
inplaceInstallPrompt: false,
isWindowless: 'false',
version: '2.0'
},
events: {
onError: onSLError,
onLoad: onSLLoad
},
initParams: "...",
context: null
});
function onSLLoad(sender, args) {
}
function onSLError(sender, args) {
// alert('error');
}
Other thoughts:
If your javascript error handler fires, the instantiation has failed. Silverlight will not suddenly come back to life by itself. Instead, call CreateObjectEx to give it another shot ;)
There are 2 kinds of terminal errors in Silverlight. 1) Managed errors (hit the managed Application_UnhandledException method). Note that some errors may not even get to this point. If the managed infrastructure can't be loaded for some reason (out of memory error maybe...), you won't get this kind of error. Still, if you can get it, you can use a web service (or the CLOG project) to communicate it back to the server. 2) Javascript errors. These are what you're getting right now. I recommend bouncing these back to your server with JQuery (or Javascript library of preference). Something like:
$.post(this.href, { func: "countVote" },
function(data) {...}
How you handle this on the server, of course, is dependent on what your server stack looks like. It's super easy in MVC, btw.