RadaeePDF.com :: Topic: PDFViewer lib subclassing / request for changes (1/1)
Welcome, Guest
Username: Password: Remember me

Signin/Signup with:

Questions about Android development and PDF

TOPIC: PDFViewer lib subclassing / request for changes

PDFViewer lib subclassing / request for changes 3 years 8 months ago #4949

  • bsautere
  • bsautere's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 6
  • Karma: 0
We had to customize the PDFViewer lib behavior. But we wanted to do that without modifying your code.
So we can always use the latest pdf lib version, easily and with no risk of losing our changes.
We did that by subclassing PDFReader.java . But we still had to do some minor changes to PDFReader.java and Global.java.

Our request is to integrate those minor changes into the official PDFViewer code, which may help other pdf lib customers as well.

Those changes are :

Visibility changes in PDFReader.java :

1 - field PDFView m_view -> protected
We have custom annotation behavior. On display we show a custom annotation icon (an icon made by us) and use m_view.vGetX() and .GetY() to place it correctly.
On touch we use m_view to replace the annotation by some custom contents.

2 - method onTouchAnnot(MotionEvent event) -> protected
We wanted to avoid moving annotations (see www.androidpdf.mobi/forum/roadmap-and-re...otations-being-moved).

3 - fields STA_NORMAL, STA_SELECT, STA_INK, STA_RECT, STA_ELLIPSE, STA_NOTE, STA_LINE, STA_ANNOT -> protected
We need to access those fields when overriding :
- OnPDFLongPressed (we show a special menu when doing long press)
- OnPDFSingleTapped (we hide the special menu)
- onTouchAnnot (point 2)

4 - field m_status -> protected
Same need as point 3.

Added functionality in Global.java :

5 - Ability to share code across projects, thus across license keys, as requested here (www.androidpdf.mobi/forum/Android-develo...nd-multiple-licenses).
We have potentially dozens (and counting) applications in iOS that will need an Android version.
Those applications have same functionalities and differ only by package, settings and contents.
So we use common code and each application hold a minimal set of media and configuration files.
That is the reason why we had to modify your code so the license key is no more hardcoded and we can use it as a shared library.
This need may be specific to us, and if you don't want to modify your code that way, you could at least provide a solution by subclassing or use of callbacks.

Modified behavior in PDFReader.java :

6 - Commenting "show available memory" code in onDraw(Canvas) : couldn't we use a debug flag or something instead of commenting ?

Maybe you should extend the visibility changes to other methods / fields so most of the futur needs are covered by subclassing.

And of course if you have better solutions to our needs, we would like to know.

Best regards,

Bernard
Mediancer Sàrl
Last Edit: 3 years 8 months ago by rhys. Reason: Forgot about commenting "show available memory" in onDraw(Canvas)
The administrator has disabled public write access.
Powered by Kunena Forum