Once in a game I was playing, a smart person wrote a cheat that allows you to disconnect all players from the server. I became interested in how it is possible to create protection against this. The situation was aggravated by the fact that the person who created the cheat distributed it to other players and disconnecting from the server became a regular event.
I got the source code of this cheat, I will show a fragment with a "connection switch":
I figured out how the cheat works. In the LLDB debugger, I found the Disconnect() function, it is called just when the "cheater" uses the cheat. In the disassembler, I decided to just remove Disconnect (), of course this is stupid, because I violated the logic of the game because of which I could not play. As a result of something, this function was called for me, I need to find out what code was executed before the breakpoint with Disconnect ()
Well its hard to tell, but my suggestion is you add some Debug.Log prints in certain scripts you think could be called before the disconnection happens, I know this sounds like a tedious work but you probably have some scripts you think could be called before. Else I would search for some keyword like "kickall" and be sure to set "all files in project" option so that it shows all possible candidates. I hope this serves you
Related
My app gets stuck for a specific operation and that operation is too big having so many method calls and services requests, so i cannot put breakpoints on each method and debug, is there any other way i can get to know where exactly my app is stucked in xcode?
The operation wasn't too big to write the code, so it isn't too big to add breakpoints, logging statements, assertions and so on.
The only other way that works sometimes is taking a long shower in the morning, not thinking about work at all, and suddenly the realisation what you did wrong jumps to your mind. It has worked for me sometimes, but the first method is more reliable.
If you have reason to believe that the most time is spent in one operation, just let it run with the debugger attached and then press the pause button and see where you are...
A somewhat niftier approach would be to start with Instruments (i.e. the Time Profiler). It's easy to use and should be the first weapon of your choice for performance issues.
You can set a conditional break point in Xcode to debug a specific condition, for more detail go through Jeffrey Sambells blog!
I am about to complete the project and I want to add logging in it. I know there are some good loggers are available in market(CocoaLumberjack). But for that I need to add log statement into each and every method. As project is about to complete there are lots of methods. So, is there any way or work around ? Without adding log statement into all methods If I will add at any central place and it will work for all.
I am not sure if there is such Objective-C runtime function that is called before every method.
This method will be helpful in all cases like I am or any new dev is writing new method then he don’t need to remember to add log statement.
Edit:
This is just for a debugging purpose. And I will add a way to control the logs like turn off and print detail of certain level.
Don't do this. Seriously. Users don't appreciate their log files filling up because of chatty software, and you'll also annoy every other developer by obscuring messages that are actually important.
You should only use NSLog() this way as an absolute last resort during debugging. Even then, there are better approaches (e.g. you could use dtrace; if you get it to dump all objc_msgSend() invocations, you'll see almost all of your method calls, aside from those that pass through objc_msgSendStret() and the floating point ones if applicable to your platform).
If you really must make a chatty application, create your own log file, write your own logging function (ideally using asl), and it’s a good idea even then to have a set of flags that can be controlled e.g. from user defaults to enable different kinds of debug output.
How about a category of NSObject with this override?
-(BOOL)respondsToSelector:(SEL)aSelector {
printf("Excessive Log: %s\n", [NSStringFromSelector(aSelector) UTF8String]);
return [super respondsToSelector:(aSelector)];
}
Here is a simple question.
suppose that I have a very long loop to execute, It would be nice to keep the user informed about the progressing right? I would print for example the number of loops that have been executed so far and how many are remaining.
The problem that I have is those output wouldn't be visualized until the the loop is finished, and thus there will be no point for them to be displayed.
I'm sure that there is some method in dart that can some sort of a handler to the browser to execute tasks and events whenever I want to and keep running the loop.
I'm new to dart, I hope that someone could answer this question.
Thank you.
PS: If you don't know how to, you can give me any ideas of keywords that I can use to look for this particular feature in dart documentation, it will be very helpful.
You can dig into Isolates, which allow background work on supported browsers.
https://api.dartlang.org/docs/channels/stable/latest/dart_isolate.html
Nothing as simple as DoEvents(), but all of the pieces are there.
I think too that Isolates are the best approach but wasn't successful using them on the browser a while ago, but there was a bigger refactoring going on lately in Isolates.
Does anyone know of a current client side Isolates example?
The API doc referenced by #kevmoo contains a link to an Isolates article that doesn't exist anymore (maybe must be rewritten due to the mentioned refactoring).
Another approach would be a method that returns after a chunk of work and gets recalled repeated in a loop until it returns for example true for done (false for not yet).
When you call this method using scheduleMicrotask(doChunk) or new Timer(() => doChunk()) other tasks get some air (import 'dart:async';) each time before the method gets actually called.
I would like to create a device that will log when a person falls asleep. Of course, someone can't just open a software application and make an entry say "fall asleep, 10:13pm" and be asleep a few seconds later. Instead, I was thinking about hacking a blackberry to log whenever a person powers it on to check the current time. The specific algorithm is not important, but is it possible to write a piece of code be written to intercept the power on button and write the current time/date to a file? If so, how is it done?
Also, if anyone has a simpler idea, please share.
I haven't tested it, but since you're asking for ideas:
You have your application running in background (or even an app which doesn't extend UIapplication) and have a Task (using Timer and TimerTask) that repeatedly checks if Backlight.isEnabled() returns true. If it does - somebody is using the phone. You can even incorporate an AlertListener class to check when the user has been woken up ;)
The downside of this solution (if it works) is that it is something of a 'busy waiting loop', so intercepting some event would be much better.
As far as writing down the current time is concerned - it's possible and sample code snippets are everywhere, you can of course use the persistent store or an SQLite table to aggregate the results in an interesting way.
Funny thing is I've been thinking about an app like this lately - it might be an good idea.
I worked my way through the Prism guidance and think I got a grasp of most of their communication vehicles.
Commanding is very straightforward, so it is clear that the DelegateCommand will be used just to connect the View with its Model.
It is somewhat less clear, when it comes to cross Module Communication, specifically when to use EventAggregation over Composite Commands.
The practical effect is the same e.g.
You publish an event -> all subscribers receive notice and execute code in response
You execute a composite command -> all registered commands get executed and with it their attached code
Both work along the lines of "fire and forget", that is they don't care about any responses from their subscribers after firing the event/executing the commands.
I have trouble seeing a practical difference in usage although I understand that the implementation of both (under the hood) is very different.
So should we think of what it actually means - Event? Is that when something happens (an event occurs)? Something the user did not directly request like a "web request completed"?
And Command? Does that mean a user clicked something and thus issued a command to our application, requesting a service directly?
Is that it? Or are there other ways to determine when to use one of these communication vehicles over the other. The guidance, although one of the best documentations I read, gives no specific explanation.
So I hope people involved in/using Prism can help in shedding some light on this.
There are two primary differences between these two.
CanExecute for Commands. A Command
can say whether or not it is valid
for execution by calling
Command.RaiseCanExecuteChanged() and
having its CanExecute delegate
return false. If you consider the
case of a "Save All"
CompositeCommand compositing several
"Save" commands, but one of the
commands saying that it can't
execute, the Save All button will
automatically disable (nice!).
EventAggregator is a Messaging
pattern and Commands are a
Commanding pattern. Although
CompositeCommands are not explicitly
a UI pattern, it is implicitly so
(generally they are hooked up to an
input action, like a Button click).
EventAggregator is not this way -
any part of the application
effectively raise an EventAggregator
event: background processes,
ViewModels, etc. It is a
brokered avenue for messaging
across your application with support
for things like filtering,
background thread execution, etc.
Hope this helps explain the differences. It's more difficult to say when to use each, but generally I use the rule of thumb that if it's user interaction that raises the event, use a command for anything else, use EventAggregator.
Hope this helps.
Additionally, there is one more important difference: With the current implementation, an event from the EventAggregator is asynchronous, while the CompositeCommand is synchronous.
If you want to implement something like "notify that event X happened; do something that relies on the event handlers for event X to have executed", you either have to do something like Application.DoEvents() or use CompositeCommands.