The Files Changed are-
The concept of the compression manager is that it is a central component that handles all compression tasks (think of it kind of like a singleton).
By making it a fragment (essentially a view/controller component) you tie it to navigation and application lifecycle constraints.
A solution that would be much cleaner both in code and design would be to make the compression manager a Service and have the compression dialog fragments bind to it to provide asynchronous task progress updates and controlling.
Hope this helps,
George.
That being said, the reasons stated above are still valid and I strongly suggest that it becomes a Service that handles all compression tasks.